[
https://issues.apache.org/jira/browse/TINKERPOP-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16778027#comment-16778027
]
Robert Dale commented on TINKERPOP-2170:
----------------------------------------
In general, equality between floats and/or doubles should not be relied upon
regardless of language. At best, between(x-tolerance,x+tolerance) should be
used.
[https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/]
[https://randomascii.wordpress.com/2012/06/26/doubles-are-not-floats-so-dont-compare-them/]
> Compare.eq doesn't produce consistent results
> ---------------------------------------------
>
> Key: TINKERPOP-2170
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2170
> Project: TinkerPop
> Issue Type: Bug
> Components: process
> Affects Versions: 3.3.4
> Reporter: Daniel Choi
> Assignee: Daniel Kuppitz
> Priority: Major
>
> https://issues.apache.org/jira/browse/TINKERPOP-2056 introduced a change to
> start using NumberHelper for comparisons.
>
> This seems to have introduced an interesting side effect:
> {code:java}
> Assert.assertTrue(Compare.eq.test(new Double(1.53), new Float(1.53)));
> {code}
> now fails in 3.3.4+ versions. Interestingly,
> {code:java}
> Assert.assertTrue(Compare.eq.test(new Double(1.5), new Float(1.5)));
> {code}
> works fine. It seems the problem is coming from the fact that the
> NumberHelper.DOUBLE_NUMBER_HELPER is chosen for the comparison of float and
> double numbers, where
> {code:java}
> new Float(1.53).doubleValue();
> => 1.5299999713897705
> new Double(1.53).doubleValue();
> => 1.53{code}
> Not sure what the correct implementation here would be, but nonetheless this
> seems to be a backwards incompatible change.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
