On Wed, Aug 28, 2024, at 8:27 AM, Marc Nieper-Wißkirchen wrote:
> If those "loopholes" are interpreted in the way you do here, what is
> the actual meaning of x|p then?  Adding an explicit mantissa width
> becomes somewhat meaningless when an implementation is allowed to
> ignore it in any case.

You appear to be assuming there is some objective "actual meaning
of x|p".  In my opinion, the purpose and specification of that notation
has never been defined so well as to create an objectively actual
meaning.

> Moreover, interpreting those loopholes in that way seems to confound
> the meaning of the various exponent marks (s, f, d, l) with the meaning
> of the explicit mantissa width.

The meanings of those exponent markers are implementation-dependent
as well, but it seems to me their meanings are more well-defined than the
meaning of the x|p notation.

> Maybe we can simplify the discussion by looking at exact numbers where
> any machine floating point representation does not play a role.
>
> The sentence
>
> "A representation of a number object with nonempty mantissa width, x
> |p, represents the best binary floating-point approximation of x using
> a p-bit significant."
>
> from R6RS implies that
>
> #e0.1|1
>
> denotes the number 1/8.  (And applying the inexact procedure to that
> number gives 0.125 regardless of any specific machine floating-point
> format.)

I disagree with your interpretation.  It seems to me that "the best binary
floating-point approximation of x" will depend upon specifics of the
floating-point system adopted by an implementation, and that the sentence
as written gives priority to that implementation-dependent choice of floating
point approximations ahead of the "using a p-bit [significand]" phrase, which
appears to me to have been an unsuccessful attempt to add some too-little,
too-late qualification to the implementation-dependent choice of floating point
that has already been implied by the phrase that precedes it.

> Chez Scheme, however, evaluates #e0.1|1 to 1/10.

One could argue that is a bug.  On the other hand, one could argue that
pretending it is possible to convert an ambiguous and poorly specified
notation such as 0.1|1 into an unambiguous and well-specified notation
by prefixing it with #e is folly.  The #e can't undo the ambiguity and poor
specification of a notation that follows it.

In summary, I think the x|p notation is a classic example of how attempts
to over-specify relatively unimportant corner cases for the purpose of
improving compatibility between implementations often create even more
opportunities for incompatibility between implementations.  If not for the
existence of the x|p notation, someone who wants to write the number 1/8
would simply write 1/8 or #e0.125 or .125 (depending on the desired property
of exactness), and there would be no question as to what is meant.

Will