On Sat, Aug 15, 2009 at 11:16 AM, Chris Hostetter<hossman_luc...@fucit.org> wrote: > > : We could either: > : - change function queries to use doubles internally - probably a good > : idea for the future in general - seems like geo might need more > : precision too. > : - come up with a new date scale function that uses doubles internally? > > off the cuff idea i remember thinking of a long time back: couldn't we add > a "getNativeType():Class" method to either ValueSource or DocValues, which > callers (and ValueSources that wrap other valuesources) could use to help > them infer what method to use on DocValues to get the value with the > highest degree of precision?
Yeah, I've had the same idea... typing of the functions. I think we'll get to that sooner or later, but I'm not sure it's something we can do for 1.4, and it would seem to cause a proliferation of classes (or switch statements at every level?). But perhaps we should default to double precision math, even when the operands are floats? Seems like it would help prevent rounding errors. -Yonik http://www.lucidimagination.com > by default, it would return Float.TYPE ... but subclasses could override > it. leaf subclasses (DoubleFieldSource) could have it return a hardcoded > value, while sources that wrap other sources and can perform the > calculation equally well on any type (TopValueSource) could delegate to > the wrapped source, and sources that add/lose precision as the result of a > calcaution (ScaleFloatFunction) would return the appropriate value based > (but not neccessarily equal to) the source they wrap. > > the added bonus being: no more casting every value of every field to > float, if all you really care about is some simple math on an int value > anyway. > > > > > -Hoss > >
