Re: NaNcodes -- a missed opportunity
Ivan Godard wrote:
Several such schemes were proposed. All the proposals shared a
characteristic that they were suitable for the NaN scheme of the
proposer and ruined other attractive schemes. I argued very
strongly against all proposals and in favor of leaving the
payload format undefined.
And I agree -- I was NOT proposing to standardize BFP NaN payloads.
The whole point of my note was to try to standardize ACCESS to those
payloads. It's always been possible to insert or extract raw NaNcodes
by accessing the raw bits -- at least in languages like C and assembler.
It may well be that on certain platforms the NaN payloads cannot sensibly
be interpreted as numbers, perhaps because (as bit patterns) they change
in mysterious but useful ways during propagation. On such a system my
proposed functions might be useless; indeed, extract(insert(x)) might
not be able to recover x. I suspect however that such systems are in
the minority. They do stand as a warning however against requiring too
much, such as the expected round-trip recovery mentioned above.
What my proposed functions would achieve is improved portability of
applications that use small integers as NaN payloads -- something
that has been discussed in the 1788 (Interval Arithmetic) workgroup
for example. It would cover up implementation differences such as
right-aligned vs left-aligned, bit-reversed or not. Whether NaNcodes
survive format conversions depends on that internal coding, and since
different encodings exist already, not much can be said; about the
best that can be requested (but not required) is that NaNcodes should
survive widening followed by narrowing to the original format, all in
the same radix. (For DFP more could be said: NaNcodes less than 10**6
should survive all same-radix format conversions -- and with IBM's
encoding they would survive conversions to BFP and back as well.
IBM's rule actually predates DFP -- it was designed to permit NaNcode
preservation for BFP format conversions, narrowing as well as widening.
But I am NOT trying to force others to use this encoding -- and in fact
my proposed functions are more difficult to support for BFP with IBM's
rules than with the simpler glibc rules.)
---Sent: 2011-01-22 21:55:45 UTC