[
https://issues.apache.org/jira/browse/LUCENE-3582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153272#comment-13153272
]
Uwe Schindler edited comment on LUCENE-3582 at 11/19/11 11:14 AM:
------------------------------------------------------------------
Here a patch that fixes NumericRangeQuery to correctly handle NaN. If the
upper/lower bounds == null, it will replace that by infinity and will never
match NaN (this was a bug before). If you want to hit NaN with NRQ, you can do
that only by directly hitting it using NumericRangeQuery.newFloatRange("float",
Float.NaN, Float.NaN, true, true)
This patch also handles doubles in addition to floats and uses the native Java
method without raw. Tests were modified to check for NaN, too.
The use of floatToIntBits instead of floatToRawIntBits has no real performance
impact, as this method is only used during indexing. Population of FieldCache
is unaffected. It just ensures that indexes are built with normalized NaN
values, so NRQ can work correctly.
Stored fields were already stored using the non-raw method, so this is now
consistent.
was (Author: thetaphi):
Here a patch that fixes NumericRangeQuery to correctly handle NaN. If the
upper/lower bounds == null, it will replace that by infinity and will never
match NaN (this was a bug before). If you want to hit NaN with NRQ, you can do
that only by directly hitting it using NumericRangeQuery.newFloatRange("float",
Float.NaN, Float.NaN, true, true)
This patch also handles doubles in addition to floats and uses the native Java
method without raw. Tests were modified to check for NaN, too.
The use of floatToIntBits instead of floatToRawIntBits has no effect, as this
method is only used during indexing. Population of FieldCache is unaffected. It
just ensures that indexes are built with normalized NaN values, so NRQ can work
correctly.
Stored fields were already stored using the non-raw method, so this is now
consequent.
> NumericUtils.floatToSortableInt/doubleToSortableLong does not sort certain
> NaN ranges correctly and NumericRangeQuery produces wrong results for NaNs
> with half-open ranges
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-3582
> URL: https://issues.apache.org/jira/browse/LUCENE-3582
> Project: Lucene - Java
> Issue Type: Bug
> Reporter: Dawid Weiss
> Assignee: Uwe Schindler
> Priority: Trivial
> Fix For: 3.5, 4.0
>
> Attachments: LUCENE-3582.patch, LUCENE-3582.patch, LUCENE-3582.patch,
> LUCENE-3582.patch
>
>
> The current implementation of floatToSortableInt does not account for
> different NaN ranges which may result in NaNs sorted before -Infinity and
> after +Infinity. The default Java ordering is: all NaNs after Infinity.
> A possible fix is to make all NaNs canonic "quiet NaN" as in:
> {code}
> // Canonicalize NaN ranges. I assume this check will be faster here than
> // (v == v) == false on the FPU? We don't distinguish between different
> // flavors of NaNs here (see http://en.wikipedia.org/wiki/NaN). I guess
> // in Java this doesn't matter much anyway.
> if ((v & 0x7fffffff) > 0x7f800000) {
> // Apply the logic below to a canonical "quiet NaN"
> return 0x7fc00000 ^ 0x80000000;
> }
> {code}
> I don't commit because I don't know how much of the existing stuff relies on
> this (nobody should be keeping different NaNs in their indexes, but who
> knows...).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
