On Thu, Aug 29, 2024, at 4:52 AM, Marc Nieper-Wißkirchen wrote:
> With the decimal number format, I can easily denote a number with a
> specified number of significant decimal digits.  Without an explicit
> mantissa width, I cannot denote a number with a specified number of
> significant binary digits using the decimal number format.

If you're talking about mathematical numbers rather than Scheme's
number objects, then there is absolutely no difference between 2.5,
2.50, 2.50000, and 2.5000000000000000000000000000000.

Because of that fact, the following paragraph makes sense only if
you are talking about approximations such as number objects or
representations rather than mathematical numbers. I understand
the convention that takes the number of decimal digits to be an
indication of the precision that might be adequate for some purpose,
but it should be noted that the use case and semantics I will describe
below is consistent with how that convention is applied to numerical
computations.

> I would argue that being able to specify the number of significant
> binary digits is at least as important as being able to specify the
> number of significant decimal digits in practical applications.  In the
> former case, binary digits should not be fabricated; in the latter,
> decimal digits shouldn't.  With the R6RS number format, both cases can
> be handled.

Mike Sperber has helpfully directed our attention to the fact that the
x|p notation as described in the R6RS does not have exactly the same
meaning it was given in the paper that invented the notation.

In R6RS 4.2.8, the x|p notation is introduced and discussed immediately
following the discussion of precision markers s, f, d, l, and e. That was
the context. I believe the use case that motivated R6RS's adoption of
the x|p notation runs somewhat as follows:

You want to create an external representation of some inexact number
that can be read by some other implementation, and you don't trust
other implementations to interpret the precision markers s, f, d, l, and e
in the way you would like. The x|p notation lets you tell other systems
the number object they create for x|p should use at least p bits in the
significand, and should of course also be the best approximation to the
mathematical number x that is possible using those bits.

With that use case in mind, the "or more", "if practical", and the two
"if...not practical" loopholes are reasonably interpreted as conceding
that the practical choices will usually be limited by the floating point
formats supported by the implementation that will be reading the x|p
notation. If only one floating point format (typically IEEE double precision)
is supported, then the only practical choice for the number of bits in the
significand will be determined by that format (typically 53), and the
semantics implied by the use case described in the preceding paragraph
is readily achieved by simply ignoring the |p suffix.

I am finding it quite difficult to imagine a plausible use case for which
0.1|3 should be treated the same as 0.125|3. If those two examples were
to be treated the same, it seems to me that the R6RS would have the
effect of requiring most systems to implement a rudimentary floating
point system in software, for arbitrary values of the precision p, and to
implement Bellerophon or some similar algorithm for all positive values
of p. It seems to me there would have been an uproar about this if that
arbitrary-precision-in-software implementation of floating point had been
recognized as a necessary consequence of adopting the x|p notation.
As a matter of historical fact, there was no such uproar, which suggests
to me that those who voted to approve the R6RS did not expect the x|p
notation to have that consequence, which suggests they did not expect
the x|p notation to be interpreted in a way that would require systems to
implement arbitrary-precision floating point in software.

Will Clinger