floating point - nan initializers

Ivan Senji ivan.senji_REMOVE_ at _THIS__gmail.com
Sun Feb 19 10:38:02 PST 2006


Dave wrote:
> In article <dt98cn$1ord$4 at digitaldaemon.com>, Walter Bright says...
> 
>>"Dave" <Dave_member at pathlink.com> wrote in message 
>>news:dt8o24$djh$1 at digitaldaemon.com...
>>
>>>I've never seen a big stink raised among Java or C# users about 
>>>initializing fp types to 0 - I never hear anyone complaining "if doubles 
>>>were initialized to nans instead of 0, I wouldn't have all these bugs in 
>>>my arithmetic".
>>
>>I've also heard from people who do serious numerical work that, at last, D 
>>is a language that cares about numerical analysis and its needs. Default 
>>initializing to nan is part of that - it forces the user to *think* about 
>>what he wants the initial value to be. Initializing it by default to 0 means 
>>that it can easilly be overlooked, and 0.0 can introduce undetected, subtle 
>>errors in the result.
>>
> 
> 
> Excepting nan init., I'm all for the great support that D gives to numerical
> work, but not at the expense of the great majority of developers who don't do a
> lot of "serious" numerical work day-in and day-out. Great numerics support won't
> mean anything if the general developer community does not pick up the language
> because they don't like (what they may well see as) inconsistencies in the
> initialization of basic types. You mentioned that you recently got some good
> feedback on D from the NWCUG - I wonder what they would think of initializing
> with nan vs. 0 for integral types?
> 
> I know that internal to the machine, integral and fp types are worlds apart. But
> a 'typical' developer uses floating point because they need precision past the
> decimal point, but beyond that expects integrals and floats to pretty much act
> the same.
> 
> IMO, the typical developer writing the typical program using some fp will end up
> writing most of their code like this:
> 
> double foo(...)
> {
> int i,j,k;
> double sum, dx, dy;
> //...
> for(...)
> {
> //...
> sum += dx + dy;

or maybe sum *= dx + dy;

In that case 0 is as bad as anything else. Atleast with nan, a developer 
may decide to print sum to console and find out that it is nan. But what 
if the formula is
sum = sum*dx + dy; -> this will cause subtle errors if you expected sum 
to be 1 for example. But you will get some numbers as a result but they 
are wrong even though you think they are allright, and the next thing 
you know your D-driven spaceship is falling onto Mars too fast and you 
are loosing alot of money an thinking: if only that sum was initialized 
to nan! :)

PS
I was against float.init==nan at first but got used to it, and realized 
that it is a good thing.

The policy of D is: initialize things to error states if possible. That 
unfortunatelly is imposible for int's but is for floats and chars.



More information about the Digitalmars-d mailing list