RE: Reproducibility; with appropriate limitations...

[Guillaume Melquiond <guillaume.melquiond@xxxxxxxxxxx>]

Le mardi 05 juin 2007 à 04:07 -0400, Michel Hack a écrit :
> 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.

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

I think you are over-designing these functions. For example, you don't
need a 128-bit integer, you may well use two 64-bit integers or four
32-bit integers. I think it is outside the scope of the standard to
explicitly mandate a long-enough _integer_; it should only mandate a
long-enough type (whatever it is).

You should not try to store an error code by playing with signs either,
as it would probably be a hindrance both for implementers and for users.
The function should rather be defined at a higher level:

    nanDecode(x) = (n,e) with n a sufficiently large type
                          and e a boolean, etc

Then languages can build their own functions above this definition, with
their own types and conventions, but with similar functionality
(extracting the payload and returning an error code).

On a side note, I am not really sure we need an error code. We could as
well leave the behavior of nanDecode undefined when the floating-point
number is not a NaN.

Best regards,

Guillaume