On Wednesday, 27 August 2014 at 23:51:54 UTC, Walter Bright wrote:
On 8/26/2014 12:24 AM, Don wrote:
On Monday, 25 August 2014 at 23:29:21 UTC, Walter Bright wrote:
On 8/25/2014 4:15 PM, "Ola Fosheim Grøstad"
<ola.fosheim.grostad+dl...@gmail.com>" wrote:
On Monday, 25 August 2014 at 21:24:11 UTC, Walter Bright
wrote:
I didn't know that. But recall I did implement it in DMC++,
and it turned out
to simply not be useful. I'd be surprised if the new C++
support for it does
anything worthwhile.
Well, one should initialize with signaling NaN. Then you get
an exception if you
try to compute using uninitialized values.
That's the theory. The practice doesn't work out so well.
To be more concrete:
Processors from AMD have signalling NaN behaviour which is
different from
processors from Intel.
And the situation is worst on most other architectures. It's a
lost cause, I think.
The other issues were just when the snan => qnan conversion
took place. This is quite unclear given the extensive constant
folding, CTFE, etc., that D does.
It was also affected by how dmd generates code. Some code gen
on floating point doesn't need the FPU, such as toggling the
sign bit. But then what happens with snan => qnan?
The whole thing is an undefined, unmanageable mess.
I think the way to think of it is, to the programmer, there is
*no such thing* as an snan value. It's an implementation detail
that should be invisible.
Semantically, a signalling nan is a qnan value with a hardware
breakpoint on it.
An SNAN should never enter the CPU. The CPU always converts them
to QNAN if you try. You're kind of not supposed to know that SNAN
exists.
Because of this, I think SNAN only ever makes sense for static
variables. Setting local variables to snan doesn't make sense.
since the snan has to enter the CPU. Making that work without
triggering the snan is very painful. Making it trigger the snan
on all forms of access is even worse.
If float.init exists, it cannot be an snan, since you are allowed
to use float.init.
