floats default to NaN... why?

[F i L]

On Saturday, 14 April 2012 at 18:07:41 UTC, Jerome BENOIT wrote:
> 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)

Just because mathematical equations behave differently with zero 
doesn't change the fact that zero _conceptually_ represents 
"nothing"

It's default for practical reason. Not for mathematics sake, but 
for the sake of convenience. We don't all study higher 
mathematics but we're all taught to count since we where 
toddlers. Zero makes sense as the default, and is compounded by 
the fact that Int *must* be zero.

> 0 / 0 = NaN // undefined

Great! Yet another reason to default to zero. That way, "0 / 0" 
bugs have a very distinct fingerprint.


> , which is inline with how pointers behave (only applicable to 
> memory, not scale).
>
> pointer value are also bounded.

I don't see how that's relevant.


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

Of course FP numbers are meant for coders... they're in a 
programming language. They are used by coders, and not every 
coder that uses FP math *has* to be well trained in the finer 
points of mathematics simply to use a number that can represent 
fractions in a conceptually practical way.


> D applies here a rule gain along experiences from numerical 
> people.

I'm sorry I can't hear you over the sound of how popular Java and 
C# are. Convenience is about productivity, and that's largely 
influence by how much prior knowledge someone needs before being 
able to understand a features behavior.

(ps. if you're going to use Argumentum ad Verecundiam, I get to 
use Argumentum ad Populum).


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

I gave examples which address this. This behavior is only 
[debatably] beneficial in corner cases on FP numbers 
specifically. I don't think that sufficient justification in 
light of reasons I give above.


> This is a numerical issue, not a coding language issue.

No, it's both. We're not Theoretical physicists we're Software 
Engineers writing a very broad scope of different programs.


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

Only useful because C defaults to garbage.


> I would even say that D may go further by setting a kind of NaN 
> for integers (and for chars).

You may get your with if Arm64 takes over.