[
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.
