On 9/11/05, J.Pietschmann <[EMAIL PROTECTED]> wrote: > > Phil Steitz wrote: > > 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, > > Ok, this makes sense. > > > > Before the change, "0 + NaN * i" was not equal to "NaN + i" for example, > > It can be argued this is correct behaviour, while: > > > wheras "isNaN" returns true for both. > > this may be misleading (although still correct). > > J.Pietschmann
So which do you prefer? I don't think we can change the isNaN behavior. It seems more natural to me in any case for NaN in either part to make the complex number NaN and, as I said above, this is also consistent with what the operations do - most have an isNaN check at the beginning and return Complex.NaN if an operand "isNaN". It seems more natural to me at least to view all values with either part NaN to be the same and equal to Complex.NaN. By definition, complex numbers have real numbers as their real and imaginary parts. When one of these is NaN, the result is not a complex number. Note this is not the same as when one of the values is infinite. Going through the (old) archives, I remember at one point we were talking about adhering to C9x Annex G: IEC 559-compatible complex arithmetic*. *I can't put my hands on that spec right now, but I will have a look to see what the recommendation is. It looks like Colt / VNI identifies NaN values as I am proposing, but there is a note in the javadoc saying this is contrary to the Annex G spec. i will look into this. Phil --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
