Re: YES on Motion P1788/M0029.02:Level3-InterfaceOnly
On 2012-01-04 12:15:49 -0500, Ian McIntosh wrote:
> VL> Should sNaN be excluded from the Empty representation? This would
> VL> avoid unnecessary exceptions in the computations.
>
> Signaling NaNs aren't widely used, but can be very helpful. One use is in
> finding uninitialized floating point variables, by asking for auto and/or
> heap memory to be initialized to Signaling NaNs. (That doesn't work for
> C/C++ static or extern variables because those languages define static and
> extern to be initialized to zeros.) I hope that uninitialized interval
> variables can be detected the same way. Uninitialized variables are one of
> the worst forms of bugs.
I agree that signaling NaN's can be helpful, but primarily for
floating-point arithmetic, when this can be controlled by the
programmer. Here I don't see the need, unless some form of
"uninitialized interval" is introduced in the standard or if
the standard requires that when a sNaN is used in an input,
the invalid exception must occur. But wouldn't decorations be
the proper way to handle "uninitialized variables"?
> Since Signaling NaNs can only be explicitly created, never the result of
> some other operation like add, an exception from using one is never
> unnecessary unless software is creating them for some specific purpose. I
> can imagine using them for some form of extension to 754; eg, as a
> representation other than 754 Infinity for an overflow, along with software
> to support that.
The fact that they cannot be the result of an operation is one of
the reasons I proposed to disallow them: this won't be a problem
for the implementation.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)