Re: Fw: Useless sNaNs... or useful?
On Fri, Oct 15, 2010 at 3:14 PM, Dan Zuras Intervals
<intervals08@xxxxxxxxxxxxxx> wrote:
>> Subject: Fw: Useless sNaNs... or useful?
>> To: stds-1788@xxxxxxxxxxxxxxxxx
>> From: Ian McIntosh <ianm@xxxxxxxxxx>
>> Date: Fri, 15 Oct 2010 14:25:31 -0400
>>
>>
>>
>> . . .
>>
>> One important use is to initialize all floating point variables to
>> signaling NaNs. If they are inadvertently not properly initialized lat=
>> er,
>> you will be told if the program attempts to use them. I used to use a
>> pre-754 system that had an option to initialize everything to their
>> equivalent of a negative signaling NaN with the payload containing that=
>>
>> particular memory address and a few other bits to make it likely to fai=
>> l if
>> used as a pointer or subscript. That found bugs even in some carefully=
>>
>> written programs that "worked" on other systems (just not correctly). =
>> I
>> know of companies doing this themselves today. It would be a worthwhil=
>> e
>> feature in every system, and doesn't depend much on NaN portability. I=
>> t is
>> affected by the second imperfect portability - whether the payload is o=
>> r is
>> not preserved.
>>
>> . . .
>>
>> - Ian McIntosh IBM Canada Lab Compiler Back End Suppor=
>>
>
> I know of no companies doing this today.
It is not up to companies. It is up to software implementors.
For example, C++ requires an initialization procedure for any
non-trivial data type. The software designer can use the constructors
to initialize the members of the data type as they see fit. For
performance reasons one might not initialize the component members.
But for correctness, I always stuff a qnan into any floating point
field that I cannot compute and then render read-only.
Many people tend to use "safe" numeric values such as zero, minus one,
+/- numeric_limits<>::max(), or numeric_limits<>::infinity(). But all
of those initializations are dangerous because they can be
inadvertently lost. NaNs are defined for just those cases where
losing a special value is unacceptable -- i.e., most un-initialization
situations.
Over time I expect people to migrate to more careful implementation,
which means more usage of NaN.
Personally I am agnostic on the issue of signalling. It is not
well-enough implemented to be widely useful, so I tend to just use
QNaN.
>
> Please name them.
All of those that are both sane and careful (admittedly a rare combination).
Lee Winter
Nashua, New Hampshire
United States of America