You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Uwe Schindler (Commented) (JIRA)" <ji...@apache.org> on 2011/11/18 22:26:51 UTC
[jira] [Commented] (LUCENE-3582) NumericUtils.floatToSortableInt
does not sort certain NaN ranges correctly.
[ https://issues.apache.org/jira/browse/LUCENE-3582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153142#comment-13153142 ]
Uwe Schindler commented on LUCENE-3582:
---------------------------------------
Why not simply use floatToIntBits without the raw? This one normalized NaN.
We used the raw methods for speed reasons as we assumed that NaN sorting makes no sense and NumericRangeQuery cannot usefully select those values. E.g. half open ranges will select NaN values incorrectly, so an index containing NaN values is not useable with NRQ where the upper bound is null.
The same applies to Doubles, you patch is missing them.
> 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
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org