A couple of notes on the Annex G standard.
On 9/17/05, Phil Steitz <[EMAIL PROTECTED]> 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
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 t
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 poin
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 *m
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
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
Phil Steitz wrote:
When implementing hashCode I noticed that equals was distinguishing
from , which is not consistent with isNaN. I changed the semantics
to make <*,NaN> == == Complex.NaN.
I'm not sure I understand your change, but IIRC IEEE 745 requires that
a NaN doesn't compare equal to a
When implementing hashCode I noticed that equals was distinguishing
from , which is not consistent with isNaN. I changed the semantics
to make <*,NaN> == == Complex.NaN.
If there are objections, I will roll this back and change the hashCode
implementation to also distinguish these, but I thin
