Is D floating point semantics too advanced?
Hans-Eric Grönlund
hasse42g at gmail.com
Thu Aug 23 10:55:50 PDT 2007
Thank you, your comment helped me to better understand the rationale behind this behavior.
One reflection: I've been in this business for almost two decades, and I have never come across the "classic test for NaN". Not that I would have recognized it though - it doesn't look like such a test. The behavior is not consistent with that of the other numerical types (there is no special "uninitialized" value for integer types, although maybe there should be one...). Anyway, I guess all this just shows how little floating point programming I've had to do so far :-)
Hans-Eric
Oskar Linde Wrote:
> Hans-Eric Grönlund skrev:
> > Hello!
> >
> > I've written a post on my blog wondering if the floating point semantics is too advanced. The problem I have with it is that I can't write something like this:
> >
> > if (someValue == real.nan) {...}
> >
> > It will never be true, which - for me - is unintuitive.
>
> And for others, the opposite would be unintuitive. A classic test for
> NaN is
>
> if (x != x) {...}
>
> There are several reasons for the current behavior, and one of them is
> that this behavior is what a ieee 754 allows. There are a very large
> number of different binary representations of floating point numbers
> that represent NaN.
>
> Out of habit, I usually use isnan(x) to explicitly check for NaN, but x
> !<>= 0 should work as well.
>
> I agree that the multitude of floating point comparison operators can
> feel overwhelming, and I often have to check the table to be sure, but
> they are very logical if you remember that NaN always compare false with
> the non-negated operators: <, <=, ==, >=, >, <>, <>=, and therefore
> compare true with their opposites: !<, !<=, !=, !>=, !>, !<>, !<>=.
>
> --
> Oskar
More information about the Digitalmars-d
mailing list