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