"Dave" <Dave_member@pathlink.com> wrote in message news:dt8o24$djh$1@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'll go out on a limb here, and say that Java was designed by people who were unfamiliar with numerical analysis. Prof. W. Kahan points out in great detail how they missed the boat with floating point. I am not too familiar with C#, but haven't noticed its designers paid much attention to the needs of numerical analysts either.

Neither have the designers of C and C++, nor the vendors. Heck, look how most C++ compilers turned their backs on 80 bit floating point!!!

Any language that doesn't even fully support the floating point precision on the chip is not a precedent worth following, as nobody with understanding of numerical analysis has had any influence on its design. Such languages typically just copy what was done before without thinking about it.

In a previous engineering life, I *have* done numerical analysis engineering work. Not a great deal, but enough to be familiar with why floating point is the way it is, and what sorts of problems and tradeoffs it is set up to deal with. I've participated in the Numerical C Extensions Group, which tried to make C into a more reasonable language for numerical work. Prof. Kahan was instrumental in the design of IEEE 754 floating point, and its first hardware implementation on the 8087 numeric coprocessor. I've read some of his papers, and have corresponded with him. He makes a whole lot of sense.

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.

I know FORTRAN doesn't deal with nans. That's unsurprising, since FORTRAN had been around for 25 years before nans were invented.

There is a 'nan' value for pointers - null, a 'nan' value for UTF-8 chars - 0xFF - which is an illegal UTF-8 character. If there was a 'nan' value for ints, D would use it as the default, too.

Walter Bright wrote:

>>Here's an example D program, showing that using length makes it zero:
> 
> That's a bug. I'll add it to the list. 

Oh, I thought it was already on it... Glad I could help out, though.

--anders

Walter Bright wrote:

> Any language that doesn't even fully support the floating point precision on the chip is not a precedent worth following, as nobody with understanding of numerical analysis has had any influence on its design. Such languages typically just copy what was done before without thinking about it.

IMHO:
Adding 128-bit floating point to the D language spec would help here...
It fits in nicely with the other types, and shows of looking forward ?

quad         128 bit floating point (reserved for future use)

--anders


See http://www.digitalmars.com/d/archives/digitalmars/D/31899.html (RFE)

"Walter Bright" <newshound@digitalmars.com> wrote in message news:dt98cn$1ord$4@digitaldaemon.com...
> 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.

And most of the time, I *think* that I want it to be 0.  It's a rare occasion that I don't want it to be.  And I already explained that nan gives me more problems than 0 would - especially in systems where the values of the numbers aren't displayed in numerical form.

> There is a 'nan' value for pointers - null, a 'nan' value for UTF-8 chars - 0xFF - which is an illegal UTF-8 character. If there was a 'nan' value for ints, D would use it as the default, too.

And so it is, then, that the two numerical types in D - integral and floating point - have two different initializers.  It makes no sense.

And again, I wonder to myself why I'm trying to convince you, because I know it won't happen.  I keep forgetting that one has to be named Don, Jill, or Matthew for one's suggestions to even be considered.

"Anders F Björklund" <afb@algonet.se> wrote in message news:dt9bsu$1s3o$1@digitaldaemon.com...
> Adding 128-bit floating point to the D language spec would help here... It fits in nicely with the other types, and shows of looking forward ?
>
> quad         128 bit floating point (reserved for future use)

I suspect any such machines will not support 80 bit floats, so the 128 bit ones would just be 'real'.

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:dt9cl0$1son$1@digitaldaemon.com...
> "Walter Bright" <newshound@digitalmars.com> wrote in message news:dt98cn$1ord$4@digitaldaemon.com...
>> 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.
> And most of the time, I *think* that I want it to be 0.  It's a rare occasion that I don't want it to be.  And I already explained that nan gives me more problems than 0 would - especially in systems where the values of the numbers aren't displayed in numerical form.

If it was default initialized to 0, there'd be no way to detect the errors that would happen in those rare cases where you didn't want it initialized to 0. At least with the nan initialization you *know* there's a bug. The nan default initialization is not there for convenience, it's there to flush out bugs.

> And so it is, then, that the two numerical types in D - integral and floating point - have two different initializers.  It makes no sense.

Every type has the default initializer that is most appropriate for that type, and each makes sense in the context of its type. Float does doesn't need to make sense in the context of int - it's very different from int, more than just nans, and treating it like an int is a sure route to bugs.

> And again, I wonder to myself why I'm trying to convince you, because I know it won't happen.  I keep forgetting that one has to be named Don, Jill, or Matthew for one's suggestions to even be considered.

Consideration is not the same thing as adopting. D can't adopt every suggestion - especially since most are mutually contradictory. (Jill thought default 0 initialization for chars makes no sense, you think non-zero makes no sense.) I'm trying to explain the rationale for how it works, that it is not some thoughtless irrational decision. If you don't agree with the rationale, that's fine, but there *is* a rationale.

If anyone thinks I've agreed with every proposal they've made, or even a fraction of them, I think they'd vehemently disagree <g>.

Walter Bright wrote:

>>quad         128 bit floating point (reserved for future use)
> 
> I suspect any such machines will not support 80 bit floats, so the 128 bit ones would just be 'real'. 

Right...


The list I had was for fixed-size formats, not variable ones.

i.e.
"half" - 16 bit floating point (storage only)
"float" - 32 bit floating point (a.k.a. single)
"double" - 64 bit floating point
"extend" - 80 bit floating point (or "extended")
"quad" - 128 bit floating point (future use)

Where "real" would just be an alias, and not a language type.

--anders

In article <dt98cn$1ord$4@digitaldaemon.com>, Walter Bright says...
>
>"Dave" <Dave_member@pathlink.com> wrote in message news:dt8o24$djh$1@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;
//...
}
return sum;
}

[compile, run, oh shit]

double foo(...)
{
int i,j,k;
double sum = 0;
//...
for(...)
{
double dx = ..., dy = ...;
//...
sum += dx + dy;
//...
}
return sum;
}

>
>I know FORTRAN doesn't deal with nans. That's unsurprising, since FORTRAN had been around for 25 years before nans were invented.
>

Yes, but even Fortran 95 doesn't do nan initialization - why?

>There is a 'nan' value for pointers - null, a 'nan' value for UTF-8 chars - 0xFF - which is an illegal UTF-8 character. If there was a 'nan' value for ints, D would use it as the default, too.
>

As I mentioned previously, I wouldn't care about fp nans then because it would be consistent for both integral and fp math operations (as seen from a 'typical' developers perspective - they'd be use to initializing everything, integral and fp alike).

Dave wrote:
> In article <dt98cn$1ord$4@digitaldaemon.com>, Walter Bright says...
> 
>>"Dave" <Dave_member@pathlink.com> wrote in message news:dt8o24$djh$1@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.

Ivan Senji wrote:

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

Then again, it's usually better to catch those bugs at compile time ?

Like in Java: (jikes compiler)
*** Semantic Error: The variable "sum" may be accessed here before having been definitely assigned a value.

Sometimes I think D has too many runtime errors, waiting to happen...

--anders