[
https://issues.apache.org/jira/browse/SOLR-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915831#action_12915831
]
Uwe Schindler edited comment on SOLR-2134 at 9/28/10 12:59 PM:
---------------------------------------------------------------
NaN is always returning false when compared to anything. Its not JVM dependent
it is mathematical correct and defined in IEEE-754 standard:
[http://en.wikipedia.org/wiki/NaN],
[http://forums.sun.com/thread.jspa?threadID=5419285]
The coolest thing is how you test for NaN (from JDK source code):
{code}
public static public boolean isNaN(double v) {
return (v != v);
}
{code}
This really returns only true for NaN, because as I said NaN always returns
inequality in any comparison. The problem with that in Lucene's/Solr's sorting
is the fact that the PriorityQueue uses lessThan which would return always
false, in any case, so the PriorityQueue gets mixed up. You can see that,
because NaN values are mixed between the other values, dependent on the order
when they were inserted.
So to remove the method call above use:
{code}
if (cached.values[doc] != cached.values[doc]) // test for NaN
{code}
Looks pervers but is correct *g*
Not related to that: One thing about your patches, some of them already
committed: Can you please use the Lucene Coding Conventions (no extra space
around if statements and the opening { at the end of a method declaration is in
the same line). We have a Eclipse style file in wiki.
was (Author: thetaphi):
NaN is always returning false when compared to anything. Its not JVM
dependent it is mathematical correct and defined in IEEE-754 standard:
[http://en.wikipedia.org/wiki/NaN],
[http://forums.sun.com/thread.jspa?threadID=5419285]
The coolest thing is how you test for NaN (from JDK source code):
{code}
public static public boolean isNaN(double v) {
return (v != v);
}
{code}
This really returns only true for NaN, because as I said NaN always returns
false in any comparison. The problem with that in Lucene's/Solr's sorting is
the fact that the PriorityQueue uses lessThan which would return always false,
in any case, so the PriorityQueue gets mixed up. You can see that, because NaN
values are mixed between the other values, dependent on the order when they
were inserted.
So to remove the method call above use:
{code}
if (cached.values[doc] != cached.values[doc]) // test for NaN
{code}
Looks pervers but is correct *g*
Not related to that: One thing about your patches, some of them already
committed: Can you please use the Lucene Coding Conventions (no extra space
around if statements and the opening { at the end of a method declaration is in
the same line). We have a Eclipse style file in wiki.
> Trie* fields should support sortMissingLast=true, and deprecate Sortable*
> Field Types
> -------------------------------------------------------------------------------------
>
> Key: SOLR-2134
> URL: https://issues.apache.org/jira/browse/SOLR-2134
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
> Reporter: Ryan McKinley
> Attachments: SOLR-2134-SortMissingLast.patch,
> SOLR-2134-SortMissingLast.patch, SOLR-2134-SortMissingLast.patch,
> SOLR-2134-SortMissingLast.patch
>
>
> With the changes in LUCENE-2649, the FieldCache also returns if the bit is
> valid or not. This is enough to support sortMissingLast=true with Trie*
> fields. Then we can get rid of the Sortable* fields
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
