Le 27/10/2020 à 09:57, Marc Nieper-Wißkirchen a écrit :
> 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!

Bitte schön !

> 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)).

Sure

> 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.
Yes the payload domain is implementation specific

> We can probably only guarantee that (nan-payload (make-nan
> (nan-payload NAN))) => PAYLOAD.
>
> But does this help to write sensible portable code?

The guarantee is:

(let* ((my-nan (make-nan payload))
        (actual-payload (nan-payload my-nan))
        (other-nan (make-nan actual-payload)))
   (nan=? my-nan other-nan))

Payload acts like error  code, they help to locate
where a  calculation issue may come  from.  Actual
payloads may  be associated  with an  error string
for instance.  To write  portable code I would use
the actual-payload  value.  If  we receive  NaN as
input it  means that  the issue already  came from
elsewhere,  maybe  it  is important  not  to  have
colliding  payload values.   If we  return NaN  as
output it is important to spot them and where they
come from.

> 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.

Yes

> - At least 51 bits of payload.

Not sure about an implementation having to offer as much as 51 bits.

Emmanuel