"Mason Green" <mason.green@gmail.com> wrote in message
news:gpt70t$2b5t$1@digitalmars.com...
> Don wrote:
>> Yup, I've had many NaN nightmares. Whenever you have an uninitialized
>> variable in C++ there's about a 1% chance that it's a NaN. That's really
>> fun to track down. NOT.
>> I think it's criminal that this feature has been in hardware since ***
>> 1980 *** and not made available even in systems languages.
>
> I second adding this feature to D. I've spent many, many hours chasing
> NaN bugs when porting box2d from c++. Most of the time, it came down to
> simply forgetting to initialize a float somewhere. I actually make a post
> on dsource a few days ago:
>
> http://www.dsource.org/forums/viewtopic.php?t=4501&sid=2e8f71e52efbcece43a63cbb261e8706
>
Warnings or errors on the use of uninitialized variables would also solve
that problem *wink* *wink* *nudge* *nudge*.

Walter Bright wrote:
> Georg Wrede wrote:
>> Thanks, Don and Walter!!
>
> I originally had this in the Digital Mars C compiler years and years
> ago. I dropped it and moved away from it because not a single person
> noticed or cared about it, plus the standard C spec failed to
> distinguish between quiet and signaling nan's.
>
> I'm glad to see it actually being of value, and it's a great idea.
I noticed there was a place in the backend where it was careful to
preserve the signallingness <g> of NaNs. So I thought, hmm, someone's
been here before.
The key thing that makes it possible is that D initializes all floats to
NaN anyway, and since C doesn't do that, it's not as obviously
beneficial. By making NaN the default, you've made sure that practically
every D user knows about them. I bet that's not the case for C/C++. (I
even know numerical analyists who don't know much about them).

Don wrote:
> Walter Bright wrote:
>> Georg Wrede wrote:
>>> Thanks, Don and Walter!!
>>
>> I originally had this in the Digital Mars C compiler years and years
>> ago. I dropped it and moved away from it because not a single person
>> noticed or cared about it, plus the standard C spec failed to
>> distinguish between quiet and signaling nan's.
>>
>> I'm glad to see it actually being of value, and it's a great idea.
>
> I noticed there was a place in the backend where it was careful to
> preserve the signallingness <g> of NaNs. So I thought, hmm, someone's
> been here before.
Like a chicken that still has genes for dinosaur teeth lurking unactivated!
>
> The key thing that makes it possible is that D initializes all floats to
> NaN anyway, and since C doesn't do that, it's not as obviously
> beneficial. By making NaN the default, you've made sure that practically
> every D user knows about them. I bet that's not the case for C/C++. (I
> even know numerical analyists who don't know much about them).
You can still know it's not the case for C/C++ given the crappy support
for nan in modern compilers.