On Nov 13, 2009, at 1:35 PM, Yonik Seeley wrote: > On Fri, Nov 13, 2009 at 1:31 PM, Grant Ingersoll <gsing...@apache.org> wrote: >> Yeah, in the end, Lucene Scorer returns a float... However, if we allow for >> pseudo fields and other capabilities, it would be nice to have doubles. > > We have doubles already... It's just that our general purpose > functions (like sum) don't use them. > geo functions could certainly use them.
Yep, I have a patch for the QueryParsing, etc. to allow me to get doubles from that. It should suffice for now. > >>> But for something like gdist(point_a,point_b), the internal >>> calculations can be done in double precision and if the result is cast >>> to a float at the end, it should be good enough for most uses, right? >> >> This is what I am doing for the specific case I'm working on, but I agree >> with Walter here. As Solr starts to evolve to power apps where you want to >> do complex functions based on the results of queries, the loss of precision >> can be quite bad. > > I agree with you all that eventually we want generic double precision support. > What I don't understand is if anyone thinks it's a blocker for geo, and why. Definitely not a blocker. I'll put up a patch on https://issues.apache.org/jira/browse/SOLR-1302 and people can kick it around.
