You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by "Kay Kay (JIRA)" <ji...@apache.org> on 2009/02/12 16:45:59 UTC
[jira] Created: (SOLR-1019) ConstantScorePrefixQuery.java -
Absolute FP comparison on getBoost()
ConstantScorePrefixQuery.java - Absolute FP comparison on getBoost()
---------------------------------------------------------------------
Key: SOLR-1019
URL: https://issues.apache.org/jira/browse/SOLR-1019
Project: Solr
Issue Type: Bug
Components: clients - java
Affects Versions: 1.3
Environment: Java 6, Tomcat 6
Reporter: Kay Kay
Attachments: SOLR-1019.patch
Absolute FP comparisons are inherently unsafe. Comparisons of FP done under an epsilon resolution difference.
affects ConstantScorePrefixQuery#toString() and #equals()
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SOLR-1019) ConstantScorePrefixQuery.java -
Absolute FP comparison on getBoost()
Posted by Lance Norskog <go...@gmail.com>.
Hey! I was going to file that!
Seriously it's nice to know that separate eyes are zeroing in on problems
this small; it means the bigger ones are gone.
On 2/23/09, Hoss Man (JIRA) <ji...@apache.org> wrote:
>
>
> [
> https://issues.apache.org/jira/browse/SOLR-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676120#action_12676120]
>
> Hoss Man commented on SOLR-1019:
> --------------------------------
>
> bq. The bottom line is that absolute FP comparisons can result in
> unpredictable behaviors, depending on the underlying implementation
> something that we want to avoid.
>
> The behavior of equality operators on floats is fairly explicit and
> unambiguous in JLS s15.21 -- if a JVM implementation produces unexpected
> behavior on these comparisons that's a bug in the JVM implementation.
>
> It's not ConstantScorePrefixQuery's job (or the job of any other Query
> class) to second guess whether the caller considers a boost value of
> X+epsilon to be "close enough" to a boost value of X to consider them the
> same query.
>
> (FWIW: I agree that equality tests on float/double values tend to
> indicate ... i just disagree with the assessment that there actually is a
> mistake in these specific cases)
>
>
> > ConstantScorePrefixQuery.java - Absolute FP comparison on getBoost()
> > ---------------------------------------------------------------------
> >
> > Key: SOLR-1019
> > URL: https://issues.apache.org/jira/browse/SOLR-1019
> > Project: Solr
> > Issue Type: Bug
> > Components: clients - java
> > Affects Versions: 1.3
> > Environment: Java 6, Tomcat 6
> > Reporter: Kay Kay
> > Attachments: SOLR-1019.patch
> >
> >
> > Absolute FP comparisons are inherently unsafe. Comparisons of FP done
> under an epsilon resolution difference.
> > affects ConstantScorePrefixQuery#toString() and #equals()
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
--
Lance Norskog
goksron@gmail.com
650-922-8831 (US)
[jira] Commented: (SOLR-1019) ConstantScorePrefixQuery.java -
Absolute FP comparison on getBoost()
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676120#action_12676120 ]
Hoss Man commented on SOLR-1019:
--------------------------------
bq. The bottom line is that absolute FP comparisons can result in unpredictable behaviors, depending on the underlying implementation something that we want to avoid.
The behavior of equality operators on floats is fairly explicit and unambiguous in JLS s15.21 -- if a JVM implementation produces unexpected behavior on these comparisons that's a bug in the JVM implementation.
It's not ConstantScorePrefixQuery's job (or the job of any other Query class) to second guess whether the caller considers a boost value of X+epsilon to be "close enough" to a boost value of X to consider them the same query.
(FWIW: I agree that equality tests on float/double values tend to indicate ... i just disagree with the assessment that there actually is a mistake in these specific cases)
> ConstantScorePrefixQuery.java - Absolute FP comparison on getBoost()
> ---------------------------------------------------------------------
>
> Key: SOLR-1019
> URL: https://issues.apache.org/jira/browse/SOLR-1019
> Project: Solr
> Issue Type: Bug
> Components: clients - java
> Affects Versions: 1.3
> Environment: Java 6, Tomcat 6
> Reporter: Kay Kay
> Attachments: SOLR-1019.patch
>
>
> Absolute FP comparisons are inherently unsafe. Comparisons of FP done under an epsilon resolution difference.
> affects ConstantScorePrefixQuery#toString() and #equals()
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1019) ConstantScorePrefixQuery.java -
Absolute FP comparison on getBoost()
Posted by "Kay Kay (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675945#action_12675945 ]
Kay Kay commented on SOLR-1019:
-------------------------------
I believe either of the scenarios in which the fix might be invalid would be related to the value of epsilon . If we keep the value of epsilon small enough - Math.Double.MIN_VALUE - we might get around the issue. The bottom line is that absolute FP comparisons can result in unpredictable behaviors, depending on the underlying implementation something that we want to avoid.
> ConstantScorePrefixQuery.java - Absolute FP comparison on getBoost()
> ---------------------------------------------------------------------
>
> Key: SOLR-1019
> URL: https://issues.apache.org/jira/browse/SOLR-1019
> Project: Solr
> Issue Type: Bug
> Components: clients - java
> Affects Versions: 1.3
> Environment: Java 6, Tomcat 6
> Reporter: Kay Kay
> Attachments: SOLR-1019.patch
>
>
> Absolute FP comparisons are inherently unsafe. Comparisons of FP done under an epsilon resolution difference.
> affects ConstantScorePrefixQuery#toString() and #equals()
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1019) ConstantScorePrefixQuery.java -
Absolute FP comparison on getBoost()
Posted by "Kay Kay (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kay Kay updated SOLR-1019:
--------------------------
Attachment: SOLR-1019.patch
> ConstantScorePrefixQuery.java - Absolute FP comparison on getBoost()
> ---------------------------------------------------------------------
>
> Key: SOLR-1019
> URL: https://issues.apache.org/jira/browse/SOLR-1019
> Project: Solr
> Issue Type: Bug
> Components: clients - java
> Affects Versions: 1.3
> Environment: Java 6, Tomcat 6
> Reporter: Kay Kay
> Attachments: SOLR-1019.patch
>
>
> Absolute FP comparisons are inherently unsafe. Comparisons of FP done under an epsilon resolution difference.
> affects ConstantScorePrefixQuery#toString() and #equals()
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1019) ConstantScorePrefixQuery.java -
Absolute FP comparison on getBoost()
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hoss Man resolved SOLR-1019.
----------------------------
Resolution: Invalid
In both the lines you suggest changing, i believe using value equality is actually more correct then an epsilon comparison given the intent of the code.
1) In toString() the intent is to display the boost when it isn't the default (1.0f), an epsilon based comparison could hide the boost value when it varies from the default by an extremely small amount. It's better to output "^1.000000001" then nothing at all.
2) In the equals method we need to know if the Query objects are ... well, equal. if the boost values vary by an amount less then the epsilon we would erroneously return true. (if i'm not mistaken, the equals change you're suggesting would actually break caching in some edge cases, because it would result in situations where...
{code}queryA.equals(queryB) && ! queryA.hashCode()==queryB.hashCode(){code}
> ConstantScorePrefixQuery.java - Absolute FP comparison on getBoost()
> ---------------------------------------------------------------------
>
> Key: SOLR-1019
> URL: https://issues.apache.org/jira/browse/SOLR-1019
> Project: Solr
> Issue Type: Bug
> Components: clients - java
> Affects Versions: 1.3
> Environment: Java 6, Tomcat 6
> Reporter: Kay Kay
> Attachments: SOLR-1019.patch
>
>
> Absolute FP comparisons are inherently unsafe. Comparisons of FP done under an epsilon resolution difference.
> affects ConstantScorePrefixQuery#toString() and #equals()
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1019) ConstantScorePrefixQuery.java -
Absolute FP comparison on getBoost()
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675963#action_12675963 ]
Yonik Seeley commented on SOLR-1019:
------------------------------------
Absolute comparisons aren't good for the result of floating point calculations, but things like boosts are pretty much always set from constants. For the very rare case that these constants are calculated, it should be up to the code doing the calculation to round or normalize if that is desired. In any case, the failure mode in this extremely unlikely event is still graceful - everything still works but the cache hit ratio goes down.
Another point: from the Lucene point of view, a boost of 0.0 and a boost of .0000001 are *very* different - lucene screens out scores <=0.0f (although Solr does not).
> ConstantScorePrefixQuery.java - Absolute FP comparison on getBoost()
> ---------------------------------------------------------------------
>
> Key: SOLR-1019
> URL: https://issues.apache.org/jira/browse/SOLR-1019
> Project: Solr
> Issue Type: Bug
> Components: clients - java
> Affects Versions: 1.3
> Environment: Java 6, Tomcat 6
> Reporter: Kay Kay
> Attachments: SOLR-1019.patch
>
>
> Absolute FP comparisons are inherently unsafe. Comparisons of FP done under an epsilon resolution difference.
> affects ConstantScorePrefixQuery#toString() and #equals()
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.