On Thu, Aug 29, 2024, at 8:57 AM, Marc Nieper-Wißkirchen wrote:
> Mike didn't say this, IIUC.  The only relevant difference is that no
> exactness prefixes are needed in his approach.  The syntax x|p in the
> paper maps to #ex|p in R6RS.

That's a pretty big difference, because an external notation of the
form #ex|p maps to an exact number object in R6RS.  You appear
to be correct in claiming the x|p syntax of the paper would always
map to an exact number object, whereas in R6RS the x|p notation
(without an explicit exactness prefix) always maps to an inexact
number object.  As I say, that seems like a pretty big difference.

>> 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.
>
> I don't understand this.

The first paragraph of the Egner/Kelsey/Sperber paper's section 7.7 says:

        Reading the mantissa-width tagged format proposed in Section 6.6
        can be done efficiently using Clinger’s method [3, 2].

Those authors neglected to note that Clinger's method is efficient only when
the specified mantissa-width matches the precision of some floating-point
format supported by hardware.  If the specified mantissa-width does not
match the hardware precision, the efficient part of Clinger's method would
have to use a software simulation of floating point that uses a matching
precision, making it no more efficient (and probably much less efficient)
than the algorithm that Clinger's method falls back on when the efficient
part of the algorithm is unable to decide upon the correct result.

> In the case of exact numbers, this is a
> simple calculation with bigints and their binary representations;

I would guess you are referring to some analogue of the inefficient
part of Clinger's method.  Clinger's method is efficient because it uses
hardware floating point to avoid that inefficient algorithm most of the
time.  Clinger's method would be inefficient when there is no hardware
support for the specified mantissa-width, and that is probably true of
your "simple calculation" as well.

> in
> the case of inexact numbers, [...] the
> explicitly given mantissa width can be truncated at the maximum number
> of significant bits (which is 53 in the case of IEEE doubles).

That's an interesting claim.  Let's assume the external representation
is being read by an implementation that supports IEEE double precision
as the only available precision for inexact reals.  From what you wrote
above, you appear to be saying

        99999999999999983222784|53

should produce the same inexact number as

        99999999999999983222784|54

in that implementation.  Am I reading you right?

> In fact, I have an implementation for Chez Scheme's reader that only
> needs a couple of lines.

Simplicity does not always coincide with efficiency.  In particular, the
inefficient part of Clinger's method is simpler than the efficient part.

Will Clinger