lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (Commented) (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3582) NumericUtils.floatToSortableInt does not sort certain NaN ranges correctly.
Date Fri, 18 Nov 2011 22:44:51 GMT


Yonik Seeley commented on LUCENE-3582:

We don't really support NaN as a value in Lucene in general I think.  I know that our sorting
(priority queue) methods don't support NaN, and this is why FunctionQuery has the following

      // Current Lucene priority queues can't handle NaN and -Infinity, so
      // map to -Float.MAX_VALUE. This conditional handles both -infinity
      // and NaN since comparisons with NaN are always false.
      return score>Float.NEGATIVE_INFINITY ? score : -Float.MAX_VALUE;
> 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: 4.0
>         Attachments: 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