commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [math] Complex equals
Date Sat, 10 Sep 2005 20:19:38 GMT
Yes, you are correct about the IEEE 745 spec, but one could argue that the 
spec applies only to primitive values - at least that seems to be the way it 
works in Java. Since equals among objects in Java *must* be reflexive, 
Double.NaN does equal itself and two Double instances with NaN value are 
equal. I don't think it would be legal for us to have equals fail for 
Complex.NaN with itself. In any case, I think it would be riskier for us to 
make Complex.NaN work that way - i.e., it is more likely that some 1.0 users 
are comparing values to Complex.NaN and relying on equals returning true.

Here is a better explanation of how things worked before my change and how 
they work now:

Before the change, "0 + NaN * i" was not equal to "NaN + i" for example, 
wheras "isNaN" returns true for both. After the change, these are equal, and 
both are equal to Complex.NaN (internally represented as "NaN + NaN * i").

Phil

On 9/10/05, J.Pietschmann <j3322ptm@yahoo.de> wrote:
> 
> Phil Steitz wrote:
> > When implementing hashCode I noticed that equals was distinguishing 
> <x,NaN>
> > from <NaN, y>, which is not consistent with isNaN. I changed the 
> semantics
> > to make <*,NaN> == <NaN,*> == Complex.NaN.
> 
> I'm not sure I understand your change, but IIRC IEEE 745 requires that
> a NaN doesn't compare equal to anything, including itself. This would
> probably mean a Complex with a NaN component shouldn't compare equal
> to anything.
> I may misremember something though.
> 
> J.Pietschmann
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message