Am Di., 27. Okt. 2020 um 09:01 Uhr schrieb Emmanuel Medernach
<xxxxxx@gmail.com>:

> Look here, this NaN interface was on version 17 of FlonumsCowan:
>
> https://small.r7rs.org/wiki/FlonumsCowan/17/source.html

Merci beaucoup!

So we have:

(make-nan PAYLOAD)
(nan-payload NAN)
(nan-signaling? NAN)

and

(nan=? NAN1 NAN).

The last one seems to be clear. It returns the value of (=
(nan-payload NAN1) (nan-payload NAN2)).

But what is the relationship between the other three procedures?

We cannot have (nan-payload (make-nan PAYLOAD)) => PAYLOAD because
PAYLOAD may contain more bits that fit into the actual payload.

We can probably only guarantee that (nan-payload (make-nan
(nan-payload NAN))) => PAYLOAD.

But does this help to write sensible portable code?

Does (nan-signaling? (make-nan PAYLOAD)) have any guarantees?

To see what guarantees can be made, let us take a look at NaN-boxing,
which will prevent Schemes from offering the full IEEE payload range:

For a double, we have 1 sign bit, 11 bits for the exponent, and 52 bit
for the fractional part. To encode a special value, the 11 exponent
bits have to be set. Moreover, at least one bit of the fractional bits
has to be set as we would get +/-inf.0 otherwise. For NaN-boxing, the
implementation will want to encode non-double values as signaling
NaNs. Otherwise, the implementation seems to be free to use the 1+52
bits. In other words, SRFI 208 could possibly guarantee that we have
52 bits of payload for quiet NaNs (this, possibly, includes +/-inf.0
if a quiet NaN actually has the relevant bit cleared). On the other
hand, the implementation may not expose any signaling NaN.

So... would the minimal guarantee be the following?

- At least quiet NaNs.
- At least 51 bits of payload.