[
https://issues.apache.org/jira/browse/GROOVY-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15856632#comment-15856632
]
Jochen Theodorou commented on GROOVY-8077:
------------------------------------------
what we use is actually compareTo in this case, and it seems, that Java is here
not doing the same break as with BigDecimal for example and says that -0<0.
This means the problem extends to Float and Double. Afaik the static compiler
and the indy port as well as prim opts do not have the problem and it is only
in DefaultTypeTransformation#compareEquals... well... not true since
f1*f2<f2*f3 should be always false. that means it is more than just
compareEquals
> double comparison (apparently) uses .equals and not ==
> ------------------------------------------------------
>
> Key: GROOVY-8077
> URL: https://issues.apache.org/jira/browse/GROOVY-8077
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
> Affects Versions: 2.4.8
> Environment: Windows (but probably generic)
> Reporter: Tomas Rokicki
>
> groovy:000> f1 = new Double(-1)
> ===> -1.0
> groovy:000> f2 = new Double(0)
> ===> 0.0
> groovy:000> f3 = new Double(1)
> ===> 1.0
> groovy:000> (f1 * f2) == (f2 * f3)
> ===> false
> This should return true. It appears (f1*f2)==(f2*f3) is being compiled to
> Double#equals(Double) where it should be compiled to unboxed float
> comparisons. IEEE874 requires -0.0 be equal to 0.0 when using a normal
> arithmetic comparison. Note that Java does the correct thing with ==.
> Double#equals(Double) (and #compareTo and #hashCode) are defined to
> distinguish negative zero from zero so hash tables "work properly".
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
