Which D features to emphasize for academic review article

F i L witte2008 at gmail.com
Sat Aug 11 17:43:10 PDT 2012


Walter Bright wrote:
>> That's just the thing, bugs are arguably easier to hunt down 
>> when things default
>> to a consistent, usable value.
>
> Many, many programming bugs trace back to assumptions that 
> floating point numbers act like ints. There's just no way to 
> avoid knowing and understanding the differences.

My point was that the majority of the time there wasn't a bug 
introduced. Meaning the code was written an functioned as 
expected after I initialized the value to 0. I was only expecting 
the value to act similar (in initial value) as it's 'int' 
relative, but received a NaN in the output because I forgot to be 
explicit.


> I don't see why this is a bad thing. The fact is, with NaN you 
> know there is a bug. With 0, you may never realize there is a 
> problem. Andrei wrote me about the output of a program he is 
> working on having billions of result values, and he noticed a 
> few were NaNs, which he traced back to a bug. If the bug had 
> set the float value to 0, there's no way he would have ever 
> noticed the issue.
>
> It's all about daubing bugs with day-glo orange paint so you 
> know there's a problem. Painting them with camo is not the 
> right solution.

Yes, and this is an excellent argument for using NaN as a 
debugging practice in general, but I don't see anything in favor 
of defaulting to NaN. If you don't do some kind of check against 
code, especially with such large data sets, bugs of various kinds 
are going to go unchecked regardless.

A bug where an initial data value was accidentally initialized to 
0 (by a third party later on, for instance), could be just as 
hard to miss, or harder if you're expecting a NaN to appear. In 
fact, an explicit set to NaN might discourage a third party to 
assigning without first questioning the original intention. In 
this situation I imagine best practice would be to write:

float dataValue = float.nan; // MUST BE NaN, DO NOT CHANGE!
                              // set to NaN to ensure is-set.


More information about the Digitalmars-d mailing list