Sean L. Palmer wrote:
> 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.

It's true that a NaN *could* hide somewhere in the code, but it's not terribly likely.  Certainly, a 0 has more chance of hiding itself all the way into production code than a NaN does.

"Russell Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3E2DC40F.2030001@deming-os.org...
> Sean L. Palmer wrote:
> > 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.
>
> It's true that a NaN *could* hide somewhere in the code, but it's not terribly likely.  Certainly, a 0 has more chance of hiding itself all the way into production code than a NaN does.

Which is why I think the compiler should deal with uninitialized variables as an error condition;  force the programmer to put something sensible into them.  Sure they'll still insert bogus values occasionally, but at least you won't get garbage or NaN.  It's a minor inconvenience compared to the headaches it would save.  Too bad Walter seems philosophically opposed to it.

Sean

"Burton Radons" <loth@users.sourceforge.net> ha scritto nel messaggio news:3E2C6F6C.3080401@users.sourceforge.net...
>
[...]
> My experience with it as a bug catch has been negative.  Perhaps I'm just more careful than most, but the one time I've forgotten to put in the initializer, four months ago when coding some OpenGL stuff, the NaN was neither a help nor a hindrance.  It was just an incorrect value that required the same amount of investigation as always to determine the
source.

That's because NaNs _propagate_  instead of  _killing_ like null pointer
faults.
Is there a way to set the CPU to throw an exception in case of NaN
arithmetic operation?
This would "catch the bug at the first debug"(TM).

Ciao

"Roberto Mariottini" <rmariottini@lycosmail.com> wrote in message news:b0qt2r$pi4$1@digitaldaemon.com...
> Is there a way to set the CPU to throw an exception in case of NaN
> arithmetic operation?
> This would "catch the bug at the first debug"(TM).

Yes, but that wouldn't be part of the official D semantics because NaNs do have legitimate uses in computation.