[
https://issues.apache.org/jira/browse/LUCENE-3582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153210#comment-13153210
]
Uwe Schindler commented on LUCENE-3582:
---------------------------------------
I agree that normalizing Nan would be goof for NRQ, because this way you can
search for NaN using:
NumericRangeQuery.newFloatRange(...., Float.NaN, Float.NaN, true, true);
Otherwise the bits produced for the bounds may not be the same bits like
indexed and thats the main problem. This would fix this issue. Another thing
to maybe fix would be the half-open ranges to correctly handle infinity. In
that case a NRQ would never hit NaN (even when half open) but with the above
query you could still search for NaN (as a "point value").
> NumericUtils.floatToSortableInt does not sort certain NaN ranges correctly.
> ---------------------------------------------------------------------------
>
> 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: 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 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]
