[math] Complex equals

[Phil Steitz <ph...@gmail.com>]

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.

If there are objections, I will roll this back and change the hashCode 
implementation to also distinguish these, but I think it is more conisistent 
with both isNaN and the way the ComplexUtils and arithmetic functions work 
to identify these values and I can't think of a realistic use case where a 
1.0 user would rely on equals distinguishing these values.

Phil

Re: [math] Complex equals

[Phil Steitz <ph...@gmail.com>]

A couple of notes on the Annex G standard.

On 9/17/05, Phil Steitz <ph...@gmail.com> wrote:
> 
> After lots of searching, I finally located a copy of Annex G on the web 
> here
> http://dev.unicals.com/papers/c99-draft.html#G.1


Note that the link above is to a draft, not the published standard, which is 
available for purchase from ISO / ANSII (in the US, here: 
http://webstore.ansi.org/ansidocstore/product.asp?sku=INCITS%2FISO%2FIEC+9899%2D1999).
There is a more recent working paper linked here:
http://www.open-std.org/jtc1/sc22/wg14/

The Annex G content is essentially unchanged in the most recent working 
paper and is still listed as "informative" (i.e., not normative). 

Phil

Re: [math] Complex equals

[Phil Steitz <ph...@gmail.com>]

After lots of searching, I finally located a copy of Annex G on the web here
http://dev.unicals.com/papers/c99-draft.html#G.1

There is no mention of equals, as this is a C language spec and what is 
being defined is a Complex C type and specs for arithmetic operations. There 
is vague wording to the effect that "infinities" should be identified, even 
when a part is NaN (G4.1#4), so the implication is that the equivalence 
classes would be

An equivalence class for each x + iy where x, y are (finite) real numbers
once class for all values that have one or more infinite parts
one class for all values that have NaN parts, but no infinite parts

I am not sure this setup would be consistent with the way we have defined 
the arithmetic operations, which do I don't think conform fully to the rest 
of the spec.

I would appreciate it if other [math] contributors would review the spec and 
weigh in on both the implementation of equals and whether we should modify 
the arithmetic function to conform fully to the spec. 

Phil

Re: [math] Complex equals

["J.Pietschmann" <j3...@yahoo.de>]

Phil Steitz wrote:
> So which do you prefer? 

A difficult question. Maybe trying to instantiate a Complex like 1+i*Nan
should result in Complex.NaN for which both Re() and Img() are NaN. This
means there is really only a single complex NaN.

> 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.

Probably the best idea anybody can come up with. I'm certainly not
able to outsmart the C9x standard developers.

J.Pietschmann

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [math] Complex equals

[Phil Steitz <ph...@gmail.com>]

On 9/11/05, J.Pietschmann <j3...@yahoo.de> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
>

Re: [math] Complex equals

["J.Pietschmann" <j3...@yahoo.de>]

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

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [math] Complex equals

[Phil Steitz <ph...@gmail.com>]

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 <j3...@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
> 
>

Re: [math] Complex equals

["J.Pietschmann" <j3...@yahoo.de>]

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