Just where has this language gone wrong?

[Era Scarecrow]

On Friday, 20 July 2012 at 08:17:03 UTC, renoX wrote:
> On Friday, 20 July 2012 at 06:40:18 UTC, Jacob Carlborg wrote:
>> On 2012-07-20 00:32, David Piepgrass wrote:
>>
>>> Actually, C# has no default initialization* of local 
>>> variables, and I love it. Instead, it is a compile-time error 
>>> to read a variable if the compiler cannot guarantee that you 
>>> have initialized it. IMO this is much better than D's "let's 
>>> initialize doubles to NaN so that something fishy will happen 
>>> at runtime if you forget to initialize it" :)
>>
>> Floats and doubles initialized to NaN can be really annoying 
>> when interfacing to C or porting to D from another language.
>
> I think that the worse part of this is that it make integers 
> and floats needlessly different..

   chars initialize to 0xff by default. By putting the values as
close to a invalid state as possible helps them to stand out as
uninitialized. There's a small part in walter's article on
demystifying the floating point, where he went onto the bugs
involved which were hard to figure out.

http://dlang.org/d-floating-point.html

[quote]
My first floating-point nightmare occurred in a C++ program which
hung once in every hundred runs or so. I eventually traced the
problem to a while loop which occasionally failed to terminate.
The essence of the code is shown in Listing 1.

[code]
double q[8];
...
int x = 0;
while (x < 8) {
    if ( q[x] >= 0 ) return true;
    if ( q[x] < 0 ) ++x;
}
return false;
[/code]

Initially, I was completely baffled as to how this
harmless-looking loop could fail. But eventually, I discovered
that q had not been initialized properly; q[7] contained random
garbage. Occasionally, that garbage had every bit set, which mean
that q[7] was a Not-a-Number (NaN), a special code which
indicates that the value of the variable is nonsense. NaNs were
not mentioned in the compiler's documentation - the only
information I could find about them was in Intel's assembly
instruction set documentation! Any comparison involving a NaN is
false, so q[7] was neither >= 0, nor < 0, killing my program.
Until that unwelcome discovery, I'd been unaware that NaNs even
existed. I had lived in a fool's paradise, mistakenly believing
that every floating point number was either positive, negative,
or zero.

My experience would have been quite different in D. The "strange"
features of floating point have a higher visibility in the
language, improving the education of numerical programmers.
Uninitialized floating point numbers are initialized to NaN by
the compiler, so the problematic loop would fail every time, not
intermittently.
[/quote]