floats default to NaN... why?

[Jerome BENOIT]

On 14/04/12 20:51, F i L wrote:
> 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"

You are totally wrong: here we are dealing with key concept of the group theory.

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

The sake of convenience here is numerical practice, not coding practice: this is the point:
from numerical folks, zero is a very bad choice; NaN is a very good one.


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

While the other (which are by far more likely) are bypassed: here you are making a point against yourself:

NaN + x = NaN
NaN * x = NaN
x / NaN = NaN
NaN / x = NaN

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

Because then zero is a meaningful default for pointers.

>
>
>> 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.
>
The above is not finer points, but basic ones.
Otherwise, float and double are rather integers than by fractions.

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

Sorry, I can't hear you over the sound of mathematics.

  Convenience is about productivity, and that's largely influence by how much prior knowledge someone needs before being able to understand a features behavior.

Floating point calculus basics are easy to understand.

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

So forget coding !

>
>
>> 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 more than sufficient because the authority for floating point (aka numerical) stuff is hold by numerical folks.

>
>
>> This is a numerical issue, not a coding language issue.
>
> No, it's both.

So a choice has to be done: the mature choice is NaN approach.


  We're not Theoretical physicists

I am

  we're Software Engineers writing a very broad scope of different programs.

Does floating point calculation belong to the broad scope ?
Do engineers relay on numerical mathematician skills  when they code numerical stuff, or on pre-calculus books for grocers ?

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

It can be initialized by 0.0 as well.
>
>
>> 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.