[jira] [Commented] (TINKERPOP-2170) Compare.eq doesn't produce consistent results
[
https://issues.apache.org/jira/browse/TINKERPOP-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16778443#comment-16778443
]
Daniel Choi commented on TINKERPOP-2170:
@[~dkuppitz]
Yes in previous versions (tested on 3.3.2), the comparison of 1.53 float and
double succeeds. Looks like the previous flow used toString -> BigDecimal
comparison flow, and toString was taking care of the "rounding", but each in
its respective number domain. So float was rounded to 1.53 based on
single-precision, instead of being based on double-precision. In reality the
float 1.53 should have been first converted to double, represented precisely as
1.529713897705078125, then rounded to 1.529713897705 in
double-precision which is not equal to
1.5300266453525910037569701671600341796875 (value closest to 1.53
in double).
{code:java}
hex bits: Float.toString(d): BigDecimal:
3fc3d707 1.526 1.5261376190185546875
3fc3d708 1.527 1.5273297119140625
3fc3d709 1.529 1.5285218048095703125
3fc3d70a 1.53 1.529713897705078125
3fc3d70b 1.531 1.5309059906005859375
3fc3d70c 1.532 1.53209808349609375
3fc3d70d 1.533 1.5332901763916015625
hex bits: Double.toString(d): BigDecimal:
3ff87ae147ae1478 1.5294
1.5293605115378159098327159881591796875
3ff87ae147ae1479 1.5296
1.5295825561427409411408007144927978515625
3ff87ae147ae147a 1.5298
1.529804600747665972448885440826416015625
3ff87ae147ae147b 1.53
1.5300266453525910037569701671600341796875
3ff87ae147ae147c 1.5302
1.53024868995751603506505489349365234375
3ff87ae147ae147d 1.5305
1.5304707345624410663731396198272705078125
3ff87ae147ae147e 1.5307
1.530692779167366097681224346160888671875
hex bits: Double.toString(d): BigDecimal:
3ff87ae13ffd 1.529713897698
1.529713897698416786852249060757458209991455078125
3ff87ae13ffe 1.5297138977
1.52971389770063723290149937383830547332763671875
3ff87ae13fff 1.529713897703
1.529713897702857678950749686919152736663818359375
3ff87ae14000 1.529713897705 1.529713897705078125
3ff87ae14001 1.529713897707
1.529713897707298571049250313080847263336181640625
3ff87ae14002 1.52971389771
1.52971389770951901709850062616169452667236328125
3ff87ae14003 1.529713897712
1.529713897711739463147750939242541790008544921875
{code}
Ok so it looks like the previous behavior can be classified as a bug and the
new behavior is simply the correct behavior?
> 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.529713897705
> 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)
[jira] [Commented] (TINKERPOP-2170) Compare.eq doesn't produce consistent results
[
https://issues.apache.org/jira/browse/TINKERPOP-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16778050#comment-16778050
]
Robert Dale commented on TINKERPOP-2170:
Just to be clear, I'm saying that this is not a bug but user error.
> 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.529713897705
> 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)
[jira] [Commented] (TINKERPOP-2170) Compare.eq doesn't produce consistent results
[
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.529713897705
> 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)
[jira] [Commented] (TINKERPOP-2170) Compare.eq doesn't produce consistent results
[
https://issues.apache.org/jira/browse/TINKERPOP-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16778010#comment-16778010
]
Daniel Kuppitz commented on TINKERPOP-2170:
---
Are you saying that this worked before? We were aware of the rounding issues,
but that's a limitation dictated by the JVM.
{noformat}
gremlin> 1f==1d
==>true
gremlin> 1.53f==1.53d
==>false
{noformat}
> 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.529713897705
> 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)
