Numbers with small mantissa widths Marc Nieper-Wißkirchen (27 Aug 2024 08:46 UTC)
Re: Numbers with small mantissa widths Michael Sperber (28 Aug 2024 14:18 UTC)
Re: Numbers with small mantissa widths Marc Nieper-Wißkirchen (28 Aug 2024 08:08 UTC)
Re: Numbers with small mantissa widths Michael Sperber (28 Aug 2024 15:14 UTC)
Re: Numbers with small mantissa widths Will Clinger (28 Aug 2024 15:12 UTC)
Re: Numbers with small mantissa widths Marc Nieper-Wißkirchen (28 Aug 2024 15:27 UTC)
Re: Numbers with small mantissa widths Will Clinger (28 Aug 2024 18:21 UTC)
Re: Numbers with small mantissa widths Marc Nieper-Wißkirchen (28 Aug 2024 21:09 UTC)
Re: Numbers with small mantissa widths Will Clinger (29 Aug 2024 04:45 UTC)
Re: Numbers with small mantissa widths Marc Nieper-Wißkirchen (29 Aug 2024 11:53 UTC)
Re: Numbers with small mantissa widths Will Clinger (29 Aug 2024 15:25 UTC)
Re: Numbers with small mantissa widths Marc Nieper-Wißkirchen (29 Aug 2024 15:57 UTC)
Re: Numbers with small mantissa widths Will Clinger (29 Aug 2024 19:21 UTC)
Re: Numbers with small mantissa widths Marc Nieper-Wißkirchen (31 Aug 2024 20:02 UTC)
Re: Numbers with small mantissa widths Will Clinger (01 Sep 2024 01:43 UTC)
Re: Numbers with small mantissa widths Marc Nieper-Wißkirchen (02 Sep 2024 15:57 UTC)
Re: Numbers with small mantissa widths Will Clinger (02 Sep 2024 23:48 UTC)
Re: Numbers with small mantissa widths Marc Nieper-Wißkirchen (03 Sep 2024 16:45 UTC)
Re: Numbers with small mantissa widths Bradley Lucier (04 Sep 2024 01:30 UTC)
Re: Numbers with small mantissa widths Marc Nieper-Wißkirchen (04 Sep 2024 06:11 UTC)
Re: Numbers with small mantissa widths Marc Nieper-Wißkirchen (04 Sep 2024 14:03 UTC)
Re: Numbers with small mantissa widths Will Clinger (13 Sep 2024 12:49 UTC)
Re: Numbers with small mantissa widths Marc Nieper-Wißkirchen (14 Sep 2024 09:43 UTC)
Re: Numbers with small mantissa widths Will Clinger (13 Sep 2024 12:50 UTC)
Re: Numbers with small mantissa widths Michael Sperber (29 Aug 2024 13:56 UTC)
Re: Numbers with small mantissa widths Marc Nieper-Wißkirchen (29 Aug 2024 11:38 UTC)

Re: Numbers with small mantissa widths Will Clinger 29 Aug 2024 04:40 UTC

On 18 October 2005 ( https://srfi-email.schemers.org/srfi-77/msg/2781383/ ),
Bradley Lucier wrote:

> The first paragraph seems to make the |p notation meaningless; it
> seems to specify nothing about the relationship between p and the
> precision of the resulting flonum.

I am not aware of any discussion of the x|p notation within the SRFI 77
mailing list during the almost 20 years that separate Brad Lucier's
remark from today's discussion.

In today's correspondence, almost 20 years later, I have argued that
the notation is ambiguous and made implementation-dependent by
the variety of reasonable interpretations that can and have been given
to the loopholes contained within SRFI 77's attempt to give meaning(s)
to the x|p notation.

On Wed, Aug 28, 2024, at 2:08 PM, Marc Nieper-Wißkirchen wrote:
> The syntax 0.1|1 is, of course, a silly example.  In practice, these
> things matter when data written by a system with, say, IEEE single
> precision, is read by a system with IEEE double precision.  The written
> external representations would be like 1.1|24; if the reading system
> ignored the mantissa width, it would fabricate binary digits that have
> never been there.

When an implementation of Scheme that uses IEEE single precision
to represent some inexact number x writes that number using the usual
decimal scientific notation, without any |p suffix, and an implementation
of Scheme that uses IEEE double precision (and no other floating point
precision) reads that external representation of x, the extra (fabricated)
bits are unavoidable.

In particular, those extra bits could not be avoided by having the single
precision implementation write an external representation of x using the
x|p notation.

On the other hand, what those extra (fabricated) bits are doing is the best
possible job of approximating the mathematical number specified by the
decimal scientific notation.  If it so happens that said mathematical number
is representable using IEEE single precision, then it will also be representable
using IEEE double precision, and the extra (fabricated) bits of its IEEE double
representation will all be zero.

So the x|p notation serves no purpose in the scenario described above.

The x|p notation also serves no purpose when that scenario is reversed,
moving from IEEE double precision to IEEE single precision.  If the bits that
are unavoidably lost during that conversion are all zero, then there will be
no loss of accuracy.  If some of those bits are nonzero, then there will be
some loss of accuracy, but that loss of accuracy is inevitable and the x|p
notation does nothing whatsoever to prevent that loss.

> But you invented the lexical syntax in SRFI 77, didn't you?  So why do
> you seem to renounce it now?  What changed since you wrote that text?

Although I invented some of the lexical syntax described in SRFI 77, I very
much doubt whether I invented the x|p lexical syntax.  Even if I did, I don't
believe I have ever taken that notation to mean what Marc Nieper-Wißkirchen
and Mike Sperber think it means.

I would point out that the third paragraph of SRFI 77's abstract slyly alludes
to the fact that its two authors did not always agree about every single aspect
of that proposal.  It should not be surprising if we still don't.

Will Clinger