Chris Hostetter-3 wrote > ...i mention this as being a workarround for floats/doubles because the > functions are evaluated as doubles (no "casting" or "forced integer > context" type support at the moment), so with integer/float fields there > would be some loss of precision.
Excellent, thank you for the reply. My initial thought was going with the extra un-indexed/un-stored field... I wasn't aware of the "docValues" attribute to be used in that case for sorting (I assume this is more for performance). Thank you for the default value explanation. I definitely like the workaround as a reindex-free option. I'm curious as to where the loss of precision would be when using "-(Double.MAX_VALUE)" as you mentioned? Also, any specific reason why you chose that over Double.MIN_VALUE (sorry, just making sure I'm not missing something)? I would think an int or long field would simply cast down from the double min/max value... at least that is what I gathered from poking around the "def()" function code. Of course, the decimal would be lost with the int and long but I would still come away with the min value of -2147483648 and -9223372036854775808, respectively. -- View this message in context: http://lucene.472066.n3.nabble.com/Numeric-Sorting-with-0-and-NULL-Values-tp4232654p4233117.html Sent from the Solr - User mailing list archive at Nabble.com.
