RE: Reproducibility; with appropriate limitations...

[Michel Hack (1-914-784-7648) <hack@xxxxxxxxxxxxxx>]

With respect to nanDecode and XnanEncode...

The only problem with using an integer to hold the payload is the
limited range.  A 32-bit integer cannot hold a binary64/decimal64
payload, and a 64-bit integer is too narrow for 128-bit formats.

This might be acceptable, as large payloads do not propagate well
anyway.  In that case, I agree that the integer should be unsigned,
or rather, that the sign should perhaps be used for a different
purpose, namely to indicate when the encoding or decoding failed.

So, use a signed integer type, and define:

   nanDecode(x) =  n  (>=0, payload of x if x is NaN, and it fits)
                = -1  (x is not a Nan)
                = -2  (x is a Nan with a large payload)

   QnanEncode(n) = x, QNaN with plus sign and given payload
   SnanEncode(n) = x, SNaN with plus sign and given payload

If n < 0 (having picked a signed integer type to permit nanDecode
to indicate errors, what should the result be?  Setting the maximum
payload is a possibility, but not a useful one except for narrow
formats where that maximum is expressible as a signed integer.

We still have to define what happens when n is too big (possible
for narrow floating-point formats), so my previous comments still
apply.   We also need to worry about SnanEncode(0) for binary
formats with the preferred Qbit convention:  should it generate
the same as QnanEncode(0) or SnanEncode(1)?  Perhaps there are
other reserved payloads that should not be settable...

If no 128-bit integer type is available, there would be no portable
way to set or extract large payloads.

Michel.

P.S.  Not sure any of this is relevant for the current PAR -- we
      should really clean up and get that done, and start thinking
      about the next one where we can address all the issues left
      open by the current one.
Sent: 2007-06-05 20:34:11 UTC