(long) sNaNs not what they could be...
> The one we were seeking was the all 1's NaN.
By 2000-2008 it was too late, but it could have been done
right in 1985: Restrict the payload to two fewer bits,
distinguish NaN from Inf by one bit, and SNaN from QNaN
by the other. It might have sped up hardware too because
Infinity could have been detected from just a few bits;
indeed, all classification (except for zeros) could have
been done on sign+exponent+twobits.
It would then have been possible (though perhaps foolish)
to support Infinities with payloads too.
That's basically what was defined for DFP, where there
was no old iron to worry about... (all-ones DFP is an
SNaN with a payload of all-nines for the DPD format, or
an SNaN with a payload of zero for BID format. So we
did mess up a bit after all... unless you treat this
as a feature, to detect the encoding from unitialised
variables)
Btw, some machines (HP's PA-RISC if I remember correctly)
do use a 1-bit to denote SNaN, and all-ones is an SNaN, but
this complicates the Quieting operation, which may have to
insert another 1-bit to prevent decaying to Infinity.
Michel.
P.S. While we're redesigning the 1985 BFP format, we should
also have defined the payload to be right-aligned, to
be beheaded or padded with zeros on the high-order end
during format conversions, so that small integers would
survive -- as they do in DFP. With IBM's conversion
rule between BFP and DFP they do survive for BPF, but
at the cost of bit-reversal in the binary format, and a
possible ambiguity in whether the bit that distinguishes
QNaN from SNaN is part of the payload or not. 754-2008
says it's not, but older software thinks it is.
The reason for propagating BFP NaNs by right-truncation
on narrowing conversions was presumably because it looked
simpler -- but the payload has to be shifted anyway because
the exponent is shorter.
---Sent: 2010-10-15 23:22:27 UTC