lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (Updated) (JIRA)" <>
Subject [jira] [Updated] (LUCENE-3582) NumericUtils.floatToSortableInt does not sort certain NaN ranges correctly.
Date Sat, 19 Nov 2011 00:40:53 GMT


Uwe Schindler updated LUCENE-3582:

    Attachment: LUCENE-3582.patch

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 does not sort certain NaN ranges correctly.
> ---------------------------------------------------------------------------
>                 Key: LUCENE-3582
>                 URL:
>             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
> 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 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:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message