Am Do., 29. Aug. 2024 um 06:40 Uhr schrieb Will Clinger <[email protected] >:
> 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. > Thank you for pointing out this email. I wasn't able to find it when I initially looked at the mail archive of SRFI 77. I don't know about the wording of the SRFI text when Bradley wrote his comment, but in R6RS, the issue is fixed, IMHO. The precision of the resulting inexact number should have at least p significant digits. In a system with IEEE singles and doubles, 1.1|50 would be represented by a double. 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. > My point is that those interpretations of the "loopholes" that make the notation ambiguous (and somewhat pointless) are not reasonable interpretations. We probably won't reach a consensus here. > 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. > 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. 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. [...] 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. > Thanks for pointing out this. Marc
