Rational: nan will propogate through an entire calculation if the developer forgets to initialize a floating point variable.

Problems:

- Inconsistent:
- Every other native type is initialized to '0'.
- Makes compilers and/or GC's more complicated to implement and maintain.
- Will probably make 'generic' programming with templates more complicated.
- using array.length on any native type will result in the elements being
initialized to 0, which is consistent with new for everything but floating
point. So for native types there's not only the default initializer
inconsistency but also another inconsistency between new and array.length.

- Unexpected/Non-intuitive:
- Because it's inconsistent within D itself (as above)
- No major language prior to D (that I'm aware of) does this
- Confusing to D newbies: Automatic initialization for a numeric type means '0'
to people coming from Java/C#. C & C++ users are used to initializing to 0.0 for
fp types so 'auto-initialization' to them will mean '0' as well.

- Unefficient:
- instead of just memset() to 0, the compiler has to also init to nan when
new'ing an array. new is literally 6x slower in a simple loop when compared to
array.length.
- Instead of using this feature, I've recently found myself working around it
using array.length (instead of new) to avoid the nan initialization overhead.
For me this also has the added benefit of initializing the added elements to 0,
which is what I expect.

- Kludgy:
- The cases where people will have to needlessly complicate their code with
things like: "fparr[] = 0;" will happen much more often than people will want to
do: "fparr[] = double.nan;"

Maybe I'm wrong.. Opinions?

Thanks,

- Dave

Dave wrote:

> Problems:
> 
> - Inconsistent:
> - Every other native type is initialized to '0'.

[...]

> Maybe I'm wrong.. Opinions?

Characters also have non-zero init values...

http://www.digitalmars.com/d/type.html:
char 	unsigned 8 bit UTF-8 	0xFF
wchar 	unsigned 16 bit UTF-16 	0xFFFF
dchar 	unsigned 32 bit UTF-32 	0x0000FFFF

But I think those should all be zero, as well.

--anders

In article <dt862v$2vi4$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>Dave wrote:
>
>> Problems:
>>
>> - Inconsistent:
>> - Every other native type is initialized to '0'.
>
>[...]
>
>> Maybe I'm wrong.. Opinions?
>
>Characters also have non-zero init values...
>

Yea - that should have read 'native numeric types', which is what I had in mind.

>http://www.digitalmars.com/d/type.html:
>char unsigned 8 bit UTF-8 0xFF
>wchar unsigned 16 bit UTF-16 0xFFFF
>dchar unsigned 32 bit UTF-32 0x0000FFFF
>
>But I think those should all be zero, as well.
>

Another vote for that as well.

>--anders

Dave wrote:
> Rational: nan will propogate through an entire calculation if the developer
> forgets to initialize a floating point variable.
> 

And this is good because you know that there is a problem. What if you are multiplying a bunch of numbers and didn't initialize to 1?

> - Unefficient:
> - instead of just memset() to 0, the compiler has to also init to nan when
> new'ing an array. new is literally 6x slower in a simple loop when compared to
> array.length.
> - Instead of using this feature, I've recently found myself working around it
> using array.length (instead of new) to avoid the nan initialization overhead.

What? This sounds like a bug to me. Seting arrays lenght with length property should also init the array. Shouldn't it?

> For me this also has the added benefit of initializing the added elements to 0,
> which is what I expect.
> 
> - Kludgy:
> - The cases where people will have to needlessly complicate their code with
> things like: "fparr[] = 0;" will happen much more often than people will want to
> do: "fparr[] = double.nan;"

Maybe, but you can always create a uninitialized array with:
float[100] fparr = void //or something like that (don't remember exactly)

Ivan Senji wrote:

>> - Instead of using this feature, I've recently found myself working around it
>> using array.length (instead of new) to avoid the nan initialization overhead.

> What? This sounds like a bug to me. Seting arrays lenght with length property should also init the array. Shouldn't it?

An age-old bug made it not initalize dynamic arrays with .init values.
This seems to be a leftover, when later resizing it by using .length...


Here's an example D program, showing that using length makes it zero:

import std.stdio;
void main()
{
   int i;
   writefln("%d", i);
   int[] ia;
   ia.length = 1;
   foreach (int i; ia)
     writefln("%d", i);

   float f;
   writefln("%f", f);
   float[] fa;
   fa.length = 1;
   foreach (float f; fa)
     writefln("%f", f);

   char c;
   writefln("%x", c);
   char[] ca;
   ca.length = 1;
   foreach (char c; ca)
     writefln("%x", c);
}

Changing the above to constructors, makes it get the proper/init values:

   int[] ia = new int[1];
   float[] fa = new float[1];
   char[] ca = new char[1];

If you resize an array, only the new parts will be zeroed out. (realloc)


See also http://www.digitalmars.com/d/archives/digitalmars/D/19780.html

--anders

"Dave" <Dave_member@pathlink.com> wrote in message news:dt85ll$2vis$1@digitaldaemon.com...
> Maybe I'm wrong.. Opinions?

I agree.  I've ended up getting _more_ bugs with the auto-initialization to nan, especially in large, complex calculations (i.e. calculating the transform matrices from position, rotation, and scaling for hierarchies of 3D objects).

On paper, having the nan propagate sounds like a good idea, but in practice, it usually ends up just being a hard, hard bug to find.  Most programs don't involve just printing out lists of floating point numbers, and so a nan in the calculations just ends up making things act strange instead of predictably (i.e. objects disappear or get skewed horribly instead of sitting still, in my 3D engine).  And 99.999% of the time I need a float, I need it initialized to 0.

Finally, the "uninitialized variables are an error" proposal seems to have fallen by the wayside (thankfully), and I make heavy use of the default value of 0 for int types, so I think that a useful default value for floats would make sense.

As for [w|d]char initializers - I think 0xFF[FF[FFFF]] is fine.  It's not like I really need chars initialized to anything - most of the time I use chars, I'm reading them in from something and so they get immediately filled with a value anyway.

"Ivan Senji" <ivan.senji_REMOVE_@_THIS__gmail.com> wrote in message news:dt8agm$2pm$1@digitaldaemon.com...
> Dave wrote:
>> Rational: nan will propogate through an entire calculation if the
>> developer
>> forgets to initialize a floating point variable.
>>
>
> And this is good because you know that there is a problem. What if you are multiplying a bunch of numbers and didn't initialize to 1?
>

I'd get 0 instead of nan and just as easily know there was something wrong. Plus it would be consistent with shorts, ints and longs.

Look, the majority of programmers out there want and expect floating point types to act like integral types except with a decimal point and greater precision, at least in the great majority of cases.

Consistency is huge - if there was a way to initialize integrals with nan then I'd say go for it across the board. But since fp types are the odd man out here I say make it consistent (0) for all.

For the programmers who want nan init they can typedef:

typedef double ndouble = double.nan;

>> - Unefficient:
>> - instead of just memset() to 0, the compiler has to also init to nan
>> when
>> new'ing an array. new is literally 6x slower in a simple loop when
>> compared to
>> array.length.
>> - Instead of using this feature, I've recently found myself working
>> around it
>> using array.length (instead of new) to avoid the nan initialization
>> overhead.
>
> What? This sounds like a bug to me. Seting arrays lenght with length property should also init the array. Shouldn't it?
>

This is consistent for everything - native types and typedefs with init, so I'm not sure this is an un-intended bug. .length will initialize the *memory*, but not the elements to the default initializer.

>> For me this also has the added benefit of initializing the added elements
>> to 0,
>> which is what I expect.
>>
>> - Kludgy:
>> - The cases where people will have to needlessly complicate their code
>> with
>> things like: "fparr[] = 0;" will happen much more often than people will
>> want to
>> do: "fparr[] = double.nan;"
>
> Maybe, but you can always create a uninitialized array with:
> float[100] fparr = void //or something like that (don't remember exactly)

Yes, but static arrays only though.

- Dave

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:dt8fmn$6vs$1@digitaldaemon.com...
> "Dave" <Dave_member@pathlink.com> wrote in message news:dt85ll$2vis$1@digitaldaemon.com...
>> Maybe I'm wrong.. Opinions?
>
> On paper, having the nan propagate sounds like a good idea, but in practice, it usually ends up just being a hard, hard bug to find.  Most programs don't

Exactly - it just kind of feels like an academic addition to the language that sounds good in the lab but doesn't work out in the field.

Why do no other wide-spread languages (that auto-initialize) initialize floats to nan? I find it hard to believe that D gets this right and the rest somehow missed it, since hardware support for nan has been wide-spread for a long time. Heck even Fortran 95 doesn't auto-initialize at all, much less to nan.

> involve just printing out lists of floating point numbers, and so a nan in the calculations just ends up making things act strange instead of predictably (i.e. objects disappear or get skewed horribly instead of sitting still, in my 3D engine).  And 99.999% of the time I need a float, I need it initialized to 0.

Auto-initialization is great, just as long as it's consistent. One of the consistent hacks against C++ is all the special little corner cases you have to remember. nan init for floats is one of those for D, and I'm convinced will cause a lot of lively chatter on D newsgroups for years to come it left as-is once more people (like you) start using D for floating point.

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

>
> Finally, the "uninitialized variables are an error" proposal seems to have fallen by the wayside (thankfully), and I make heavy use of the default value of 0 for int types, so I think that a useful default value for floats would make sense.
>
> As for [w|d]char initializers - I think 0xFF[FF[FFFF]] is fine.  It's not like I really need chars initialized to anything - most of the time I use chars, I'm reading them in from something and so they get immediately filled with a value anyway.

I'm with you, but would like to see these init'd to 0, primarily for consistency (but the OP was really about arithmetic types anyhow). Also, what's with D re-reinventing the wheel here - C# and Java both init these to 0, as they do with *all* native types (again easy to remember consistency).

But, i'd be real happy to just get rid of nan.

- Dave

"Dave" <Dave_member@pathlink.com> wrote in message news:dt8o24$djh$1@digitaldaemon.com...
> I'm with you, but would like to see these init'd to 0, primarily for consistency (but the OP was really about arithmetic types anyhow). Also, what's with D re-reinventing the wheel here - C# and Java both init these to 0, as they do with *all* native types (again easy to remember consistency).

They used to be, but Walter changed it when Arcane Jill (i.e. the founder of Unicodism, a rabid religion whose platform is that of strict acceptance and compliance of Unicode) said that it should be 0xFF, which is the "nan" equivalent for Unicode characters - that is, 0xFF means "not a valid character."  Of course, this still leaves out integral types, for which there is no nan equivalent.

One thing that all three types can represent, however, is 0 :)

"Anders F Björklund" <afb@algonet.se> wrote in message news:dt8eo8$5ol$1@digitaldaemon.com...
> Here's an example D program, showing that using length makes it zero:

That's a bug. I'll add it to the list.