Re: NaNs Just Don't Get No Respect

[Walter Bright]

On 8/19/2012 1:43 PM, Chad J wrote:
So instead of writing
     float f;
     if (condition1)
         f = 7;
     ... code ...
     if (condition2)
         ++f;

is there any way we can make it easier to write

     void someCode() {
         ... code ...
     }

     float f;
     if ( condition )
     {
         f = 7;
         someCode();
         ++f;
     }
     else
         someCode();

assuming that condition2 is true when condition1 is true?

Yes, you can do that.


I feel like NaNs are a step forward, but better can be done.  They allow error
detection, but it's still merely runtime error detection, and worse yet, it's
/non-local/ error detection.  NaNs can spread from function to function and end
up in completely different parts of a program than the place they originated.
This causes debugging hell, just like null values.

I'm sorry, it's not debugging hell. I've done an awful lot of "figure out where 
this null came from" and it's a bit tedious, but not hell. You go step by step, 
such as "it's null in this function, so put an assert on the callers of the 
function", rinse, repeat.

Yes, I also know this is more of a problem if you've got a program that's not so 
easy to rerun.

It makes me think that
non-nan-able floating point types would be very useful, at least as function
arguments, so that calling code doesn't have to introduce extra checks for NaNs
that are either lost cycles or forgotten entirely and bug-ridden.

You can use signalling NaNs, if you like.


I really wish we had a way of catching NaNs in the function or line where they
happen, and not in completely distant parts of the code.

Nobody has even mentioned this until I brought it up, so I have a hard time 
believing the current state of affairs is a terrible problem that requires a 
major redesign to fix.

I know that nobody wants to see NaNs in their results, but be assured that that 
is far, far better than corrupted results that are off in subtle ways. NaNs are 
also one hell of a lot easier to track backwards than the other.