Reproducibility; with appropriate limitations...

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

On June 1st Dave James proposed (among other things):

>    We should define a few primitives that isolate the
>    application from the details of the NaN encodings,
>    as was done with the decimal encodings.  Perhaps like:
>      x = QnanEncode(n);
>      x = SnanEncode(n);
>      n = QnanDecode(x);
>      n = SnanEncode(x);
>    where n is an unsigned integer, representing the payload,
>    and x is a floating-point format.


We need to do a bit more work to define the properties of these operations.
Here are some suggestions:

(1) There is only one nanDecode() operation, or we have to define what
    the meaning of SnanDecode(some Qnan) is.  We already have the class
    operations to extract the Snan/Qnan distinction.

(2) The functions should be homogeneous, i.e. the payload should be passed
    as a floating-point integer.  This ensures that the range is adequate.
    It also permits nanDecode(numeric) to return the default Qnan.

    For decimal format nanDecode the preferred exponent is zero.

(3) We might as well preserve the sign, blindly.

(4) The operations should be quiet, i.e. signal no exceptions.

(5) If the given payload exceeds the format's capacity, the default
    Qnan should be returned, per 7.2.3 in the current (1.4.0) draft.

    (If the default QNaN does not correspond to a payload of zero,
    should encode(large) explicitly coerce to zero instead, so as to
    make (7) below easier to state?)

(6) If the given payload is not integral, I would suggest that it be
    simply truncated (like round towards zero, but it is not a formal
    rounding as this is a quiet operation).  This is a side-effect of
    being homogeneous.  (Note that 64-bit integer formats are too narrow
    for binary128 and decimal128 payloads.)

    Alternatively non-integers could be treated as invalid, like
    excessively big integers, and the result would be as in (5) above.

(7) The sequence QnanEncode, formatOfconvert, nanDecode, when started
    with a floating-point integer, should either recover the original
    value, or return zero (assumed here to be the payload of the
    default Qnan, though that assumption may be too presumptuous).

There is a conflict here between being quiet and detecting an invalid
(i.e. excessive, or non-integral) given payload.  I was tempted at one
point to peg excessive payloads to the maximum, so an easy way to deduce
the maximum would be  nanDecode(XnanEncode(Inf))  for example.  Well, I
suppose one could always define this special case, as it does not really
conflict with coercing large finite payloads to zero.

Note that pegging large finite values would wreak havoc with (7), as the
maximum for a narrow format is an ordinary payload for a wider format.

So let me continue:

(8)  Encoding Infinity generates the largest payload for the format.

(9)  Encoding NaN is a case of quiet NaN propagation, like copy().

(10) (7) needs to be phrased more carefully to account for (8) and (9).


Michel.
Sent: 2007-06-03 16:44:45 UTC