floats default to NaN... why?

[Jerome BENOIT]

On 14/04/12 18:38, F i L wrote:
> On Saturday, 14 April 2012 at 15:44:46 UTC, Jerome BENOIT wrote:
>>
>>
>> On 14/04/12 16:47, F i L wrote:
>>> Jerome BENOIT wrote:
>>>> Why would a compiler set `real' to 0.0 rather then 1.0, Pi, .... ?
>>>
>>> Because 0.0 is the "lowest" (smallest, starting point, etc..)
>>
>> quid -infinity ?
>
> The concept of zero is less meaningful than -infinity. Zero is the logical starting place because zero represents nothing (mathematically)

zero is not nothing in mathematics, on the contrary !

0 + x = 0 // neutral for addition
0 * x = 0 // absorbing for multiplication
0 / x = 0 if  (x <> 0) // idem
| x / 0 | = infinity if (x <> 0)
0 / 0 = NaN // undefined


, which is inline with how pointers behave (only applicable to memory, not scale).

pointer value are also bounded.

>
>
>> numerical value. Pi is the corner case and obviously has to be explicitly set.
>>>
>>> If you want to take this further, chars could even be initialized to spaces or newlines or something similar. Pointers/references need to be defaulted to null because they absolutely must equal an explicit value before use. Value types don't share this limitation.
>>>
>>
>> CHAR set are bounded, `real' are not.
>
> Good point, I'm not so convinced char should default to " ". I think there are arguments either way, I haven't given it much thought.
>
>
>>>> The more convenient default set certainly depends on the underlying mathematics,
>>>> and a compiler cannot (yet) understand the encoded mathematics.
>>>> NaN is certainly the certainly the very choice as whatever the involved mathematics,
>>>> they will blow up sooner or later. And, from a practical point of view, blowing up is easy to trace.
>>>
>>> Zero is just as easy for the runtime/compiler to default to;
>>
>> Fortran age is over.
>> D compiler contains a lot of features that are not easy to set up by the compiler BUT meant for easing coding.
>>
>>
>> and bugs can be introduce anywhere in the code, not just definition.
>>
>> so the NaN approach discard one source of error.
>
> Sure, the question then becomes "does catching bugs introduced by inaccurately defining a variable outweigh the price of inconsistency and learning curve."  My opinion is No, expected behavior is more important.

 From a numerical point of view, zero is not a good default (see above), and as such setting 0.0 as default for real is not an expected behaviour.
Considering the NaN blow up behaviour, for a numerical folk the expected behaviour is certainly setting NaN as default for real.
Real number are not meant here for coders, but for numerical folks: D applies here a rule gain along experiences from numerical people.
So your opinion is good, but you misplaced the inconsistency: 0 is inaccurate here and NaN is accurate, not the contrary.

  Especially when I'm not sure I've ever heard of someone in C# having bugs that would have been helped by defaulting to NaN. I mean really, how does:
>
> float x; // NaN
> ...
> x = incorrectValue;
> ...
> foo(x); // first time x is used
>
> differ from:
>
> float x = incorrectValue;
> ...
> foo(x);
>
> in any meaning full way? Except that in this one case:
>
> float x; // NaN
> ...
> foo(x); // uses x, resulting in NaNs
> ...
> x = foo(x); // sets after first time x is used
>
> you'll get a "more meaningful" error message, which, assuming you didn't just write a ton of FP code, you'd be able to trace to it's source faster.
>
> It just isn't enough to justify defaulting to NaN, IMO. I even think the process of hunting down bugs is more straight forward when defaulting to zero, because every numerical bug is pursued the same way, regardless of type. You don't have to remember that FP specifically causes this issues in only some cases.

For numerical works, because 0 behaves nicely most of the time, non properly initialized variables may not detected because the output data can sound resoneable;
on the other hand, because NaN blows up, such detection is straight forward: the output will be a NaN output which will jump to your face very quickly.
This is a numerical issue, not a coding language issue. Personally in my C code, I have taken the habit to initialise real numbers (doubles) with NaN:
in the GSL library there is a ready to use macro: GSL_NAN. (Concerning, integers I used extreme value as INT_MIN, INT_MAX, SIZE_MAX. ...).
I would even say that D may go further by setting a kind of NaN for integers (and for chars).