[
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.5299999713897705078125, then rounded to 1.5299999713897705 in
double-precision which is not equal to
1.5300000000000000266453525910037569701671600341796875 (value closest to 1.53
in double).
{code:java}
hex bits: Float.toString(d): BigDecimal:
3fc3d707 1.5299996 1.52999961376190185546875
3fc3d708 1.5299997 1.52999973297119140625
3fc3d709 1.5299999 1.52999985218048095703125
3fc3d70a 1.53 1.5299999713897705078125
3fc3d70b 1.5300001 1.53000009059906005859375
3fc3d70c 1.5300002 1.530000209808349609375
3fc3d70d 1.5300003 1.53000032901763916015625
hex bits: Double.toString(d): BigDecimal:
3ff87ae147ae1478 1.5299999999999994
1.5299999999999993605115378159098327159881591796875
3ff87ae147ae1479 1.5299999999999996
1.5299999999999995825561427409411408007144927978515625
3ff87ae147ae147a 1.5299999999999998
1.529999999999999804600747665972448885440826416015625
3ff87ae147ae147b 1.53
1.5300000000000000266453525910037569701671600341796875
3ff87ae147ae147c 1.5300000000000002
1.53000000000000024868995751603506505489349365234375
3ff87ae147ae147d 1.5300000000000005
1.5300000000000004707345624410663731396198272705078125
3ff87ae147ae147e 1.5300000000000007
1.530000000000000692779167366097681224346160888671875
hex bits: Double.toString(d): BigDecimal:
3ff87ae13ffffffd 1.5299999713897698
1.5299999713897698416786852249060757458209991455078125
3ff87ae13ffffffe 1.52999997138977
1.529999971389770063723290149937383830547332763671875
3ff87ae13fffffff 1.5299999713897703
1.5299999713897702857678950749686919152736663818359375
3ff87ae140000000 1.5299999713897705 1.5299999713897705078125
3ff87ae140000001 1.5299999713897707
1.5299999713897707298571049250313080847263336181640625
3ff87ae140000002 1.529999971389771
1.529999971389770951901709850062616169452667236328125
3ff87ae140000003 1.5299999713897712
1.5299999713897711739463147750939242541790008544921875
{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.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)
