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