[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
RE: Reproducibility; with appropriate limitations...
-----Original Message-----
From: stds-754@xxxxxxxx [mailto:stds-754@xxxxxxxx]On Behalf Of Michel
Hack (1-914-784-7648)
Sent: Sunday, June 03, 2007 4:44 AM
To: stds-754; David James
Subject: Reproducibility; with appropriate limitations...
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 = SnanDecode(x); (sic)
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.
Seems reasonable; maybe its called PayloadDecode?
(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.
It seems they will be manipulated as integers and should thus be
returned as unsigned integers.
(3) We might as well preserve the sign, blindly.
Not sure that makes sense.
Only needed on encode; perhaps better to specify as second arg.
(4) The operations should be quiet, i.e. signal no exceptions.
Agreed.
(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?)
Hmm, not sure.
(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.
Not an issue with integers.
(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).
I presume you mean the default is returned if the payload exceeds the
capacity of the format. Seems OK.
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).
Not sure if those are issues with an integer specifier.
Michel.
Sent: 2007-06-03 16:44:45 UTC