NaNs Just Don't Get No Respect

[Chad J]

On 08/19/2012 06:16 PM, Walter Bright wrote:
> 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.
>

Most of the programs I've worked on, be it hobby games or business apps 
for pay, have been interactive stuff.  Rerunning sucks.  Debuggers also 
interact very poorly with these things, or just plain have crappy 
interfaces that make using them a legitimate pain.  My productivity is 
greatly improved by NOT having to do tedious busywork.

This is why I have a very low tolerance for non-local bugs and a lack of 
good stacktrace info when crashing.

I'd feel /a lot/ better if corrupt data like NaNs or nulls would create 
some kind of a crash or compiler error /before/ leaving the function 
that created them.

IMO, this would be a huge step forward for programmer productivity.  No 
longer does every nan/null take like 15-30 minutes to debug, it takes  1 
minute instead.

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

How?  I remember reading a lot of material on NaNs in D, but I don't 
recall these.

>> 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 doubt that preventing non-local bug propagation would require any kind 
of major redesign at this point.  D seems very close already.

Some kind of convenient notation for optional non-nullable (and maybe 
non-nan-able?) types combined with strictly simple branching 
initializations and some kind of easy-to-use sentinel values would 
probably go a long way.

There seems to be a push to try and get this functionality from 
user-defined types.  I am skeptical that it will ever work for these 
things because something like

     NotNull!MyType foo( NotNull!MyType a, NotNan!float b ) { ... }

is going to be very daunting to write and read compared to something like

     MyType@ foo( MyType@ a, float@ b )

which is just a notation I've seen in previous posts.  Initialization 
becomes a huge pain for the user-defined types too.

Not only are proxy types like "NotNull!X" far more difficult to write in 
D than I would have expected, but things like non-null types and 
possibly non-nan types would be so common that things will probably look 
very nasty if people start using proxy types for this.  I'm willing to 
wait and see if these proxy types can be made though, and if they get 
used a lot.  I just hope their clumsiness doesn't inhibit their use.  I 
understand it's easier to add things in demand than it is to remove 
things that are used infrequently.


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

I agree that NaNs are really cool.  They are definitely much better than 
"f=0;".  Thank you for doing this.