Thanks Chris. Searching for both values and retrieving the documents would be alright as long as the data was correct. In this case, the data that I am indexing into Solr is not the same data that I am pulling out at query time. That is the real impact here.
On Thu, Jul 21, 2016 at 6:12 PM, Chris Hostetter <hossman_luc...@fucit.org> wrote: > > : Hi, I am running into a weird rounding issue on Solr 5.2.1. I have a > float > : field (also tried tfloat), I am indexing 154035.26 into it (confirmed in > : the data), but at query time, I get back 154035.27 (.01 more). > : Additionally when I query for the document and include this number in > the q > : parameter, it comes up with both values, .26 and .27. > > Pretty sure what you are observing is just the normal consequences of IEEE > floats (as used by java) being base2 -- not every base10 decimal value > has a precise base2 representation. > > Quering for 154035.27 and 154035.26 will both match the same docs, because > the String->Float parsing in both cases will produce the closest *legal* > float value, which is identical for both inputs. > > If need precise decimal values in solr, you need to either use 2 > ints/longs (ie num_base="154035", num_decimal="26") or use one int/long > and multiply/divide by a power of 10 corisponding to the number of > significant digits you want in the client (ie: "15403526" divide by 100) > > > Some good reading linked to from here... > > http://perlmonks.org/?node_id=203257 > > And of course, if you really want to bang java against your head, > this is a classic (all of which is still appliable i believe) ... > > https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf > > > > > > -Hoss > http://www.lucidworks.com/ >
