[jira] [Commented] (GROOVY-8077) double comparison (apparently) uses .equals and not ==

["Jochen Theodorou (JIRA)" <ji...@apache.org>]

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