"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:b0cc2q$1qh0$1@digitaldaemon.com...
> Could you throw a compile-time warning when floats or doubles aren't explicitly initialized? Throwing a compile-time error would be harsh but a warning would save me from debugging the problem at run-time. At least a
NaN
> isn't as nasty to debug as random uninitialized memory :)

Another thing about NaNs is they'll make it clear that you've got a bug. A default 0 initialization can hide a bug, and such hidden bugs were one of the incentives to introduce NaNs.

"factory" <tehdasX@optushome.com.au> wrote in message news:MPG.189491406aa42260989681@news.digitalmars.com...
>   Hmm then why choose 0, which is a number which tends to hide and not
> cause much trouble, rather than something large that would screw up most
> calculations?

You might be right, 0xDEADBEEF might be better <g>.

"Bjornar Svingen" <bjornar.svingen@ktv.no> wrote in message news:b0cveo$2570$1@digitaldaemon.com...
> I don't know. Usually NaN tells you that some numerics is out of control, division by zero or some other divergent situation. By setting the default value to NaN you are initially "out of control" which is basicly what you are if you don't assign some value to it.

NaNs are also useful to fill in unknown values when crunching on real world data. If your result is a NaN, then you know that data is required to get a result. If your result is not NaN, then you know for sure that result doesn't depend on the unknown data.

"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:b0c8rq$1ofp$1@digitaldaemon.com...
> Yes, yes, I agree;  it's been discussed to death already.  Walter seems intent on forcing NaN's into our programs.

NaN's for the initializer are not that different from NULL for pointers - any use of a NULL pointer gets a GP fault, since NULL is guaranteed to not be a valid pointer.

In D, you can also create your own typedefs and default initializers:

    typedef double mydouble = 0.0;
    mydouble m;    // m is initialized to 0.0

Walter wrote:
> NaN's for the initializer are not that different from NULL for pointers - any use of a NULL pointer gets a GP fault, since NULL is guaranteed to not be a valid pointer.

True, but why should floats be more similar to pointers than to integers? I guess, 0 is what most people would expect, and what would save the most unnecessary typing. (Actually, saving typing is about the only point of standard initializers. Otherwise, you could simply force explicit initializers to be used.)

But then, NaN is not a bad choice either. It will be rather simple to find errors caused by it, and after killing their third bug of that kind, people will remember...

"Norbert Nemec" <Nobbi_at_theorie3.physik.uni-erlangen.de@NOSPAM.COM> wrote in message news:b0dlq9$2fh5$1@digitaldaemon.com...
> Walter wrote:
> > NaN's for the initializer are not that different from NULL for
pointers -
> > any use of a NULL pointer gets a GP fault, since NULL is guaranteed to
not
> > be a valid pointer.
> True, but why should floats be more similar to pointers than to integers?

Unfortunately, there is no invalid bit pattern for integers. But there is for pointers and IEEE floats, so might as well make use of it.

> I
> guess, 0 is what most people would expect, and what would save the most
> unnecessary typing. (Actually, saving typing is about the only point of
> standard initializers. Otherwise, you could simply force explicit
> initializers to be used.)

The issue is more about minimizing the potential for bugs than saving typing.

> But then, NaN is not a bad choice either. It will be rather simple to find errors caused by it, and after killing their third bug of that kind,
people
> will remember...

I'd rather have a NaN show up in the result meaning I *know* there's a bug, than a result that is slightly wrong that slips by.

NaNs have been around for 15 years or so, and few people use them. (Also, few C/C++ compilers ever bothered to support NaNs, meaning people who wanted to use them had to resort to ugly hacks.) NaNs rarely seem to be mentioned in numerical computing papers. I think they are a most overlooked tool. You could, of course, argue that they are overlooked for good reason that I am missing, but I think they are overlooked simply because people don't know what they're useful for.

"Walter" <walter@digitalmars.com> wrote in message news:b0dhu8$2dov$1@digitaldaemon.com...
>
> "Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:b0c8rq$1ofp$1@digitaldaemon.com...
> > Yes, yes, I agree;  it's been discussed to death already.  Walter seems intent on forcing NaN's into our programs.
>
> NaN's for the initializer are not that different from NULL for pointers - any use of a NULL pointer gets a GP fault, since NULL is guaranteed to not be a valid pointer.
>
> In D, you can also create your own typedefs and default initializers:
>
>     typedef double mydouble = 0.0;
>     mydouble m;    // m is initialized to 0.0

Didn't know that... that is a pretty cool feature!

It's almost like a user-defined constructor for basic types.  Syntax isn't unified with UDT's but it's still nice.

Perhaps we could *change* the default initializer within a scope, such as a module or class?  Without introducing a new type name?

typedef double double = 0.0;
typedef int int = 0;
typedef char char = '\0';

You can always default-init int's to something wierd like 1 << (bits-1) == ~0u - (~0u>>1) == (0x80000000) which would be a sure sign that you forgot to initialize it.  At least then D's initialization system would be unified. I'd rather have zeros, but having it unified to NaN or some reasonable garbage would be quite tolerable.  I'd prefer just making it a compile time error if you don't initialize to something.  If it's later assigned before the initialized value is used, the compiler can strip out the initialization.

This 1 << (bits-1) makes a great garbage initializer BTW.  It's equidistant from 0 in both directions, as far away from zero as possible.

It's also potentially useful. It's tricky to compute if you don't a priori know the number of bits.  It could possibly be used to figure out how many bits are there, and whether the type is signed or unsigned.  Ok, so maybe not that useful.  Not as useful as zero.  But it seems your decision is not based on utility so much as on error trapping.

There's precedent set by various heap managers to initialize memory to 0xcdcdcdcd, 0x55555555, 0xdeadbeef, or whatever.  So long as it's large, easy to spot in a mem dump, odd, and not too close to zero, it'll work well to catch uninitialized variable bugs.  Maybe 0x7fffffff would be better than 0x80000000 since it's odd.

Sean

Oftentimes I'd rather have a zero.  We chase NaN's all the time at work. Someone takes acos(1.00000001) and poof you get a NaN.  I can't imagine the kind of NaN hell you'd be in if it was the default value.  It'll be biting people all the time.  If you run statistics it'll likely be the single largest source of runtime bugs in D.  Mark my words.  Ok maybe the C-style case fallthru will be a close second.  ;)  If a NaN creeps in anywhere in a system, all hell breaks loose with NaN's propagating everywhere until the whole system blows up.  In our game, that causes the player to disappear and the screen to flash wildly;  everything goes nuts.   All it takes is one NaN hiding somewhere in a rarely-used variable to wreak havok.  I'd rather have the compiler just force me to initialize everything explicitly.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:b0ch22$1tnk$2@digitaldaemon.com...
>
> "Mark Evans" <Mark_member@pathlink.com> wrote in message news:b0cbcb$1q0i$1@digitaldaemon.com...
> > Walter here I would toss back at you the hoary old chestnut you toss at
me
> when
> > I suggest D features that don't feel like C.
>
> Fair enough!
>
> > Using a NaN initializer may be theoretically and pedagogically proper
but
> it's
> > dumb because nobody expects it.  Zero is the value to use.
>
> The nice thing about NaN is it won't bite you if you don't expect it. 0 will.

In article <b0dh74$2dc3$2@digitaldaemon.com>, walter@digitalmars.com says...
> 
> "factory" <tehdasX@optushome.com.au> wrote in message news:MPG.189491406aa42260989681@news.digitalmars.com...
> >   Hmm then why choose 0, which is a number which tends to hide and not
> > cause much trouble, rather than something large that would screw up most
> > calculations?
> 
> You might be right, 0xDEADBEEF might be better <g>.

  Or 0xBAADF00D (which I found quite amusing at the time).. :)

  - Factory

"Walter" <walter@digitalmars.com> schrieb im Newsbeitrag news:b0dh74$2dc3$1@digitaldaemon.com...

> Another thing about NaNs is they'll make it clear that you've got a bug. A default 0 initialization can hide a bug, and such hidden bugs were one of the incentives to introduce NaNs.

Absolutly right! I stumbled about the NaN semantics too but IMO Walter took the right way. 0 is a number with mathematic semantics, NaN is not. No semantics --> no result is a good and easy rule. Robert