Am Do., 29. Aug. 2024 um 17:15 Uhr schrieb Will Clinger <[email protected] >:
> 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. > Yes. But there is a difference between 2.500 and 2.500|1. > 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. There is a well-defined mathematical meaning of binary floating-point approximation with a given number of significant bits, so I disagree. [...] > 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. > 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. > 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. This is not necessarily the case. The paragraph about +inf.0 follows the discussion of the x|p notation and it does not make sense to view it in that context. The only thing we can say for sure is that section 4.8.2. contains the paragraphs relevant for the external representation of number objects. > 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. > This is just one of the two functions of the x|p notation. > 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. > The double format does not apply when considering literals like #e0.1|1 because this is an exact (rational) number. In particular, the reasoning in the quoted paragraph about why |p can be ignored does not apply. And even in the inexact case, the semantics implied by the use case described before do not imply that the |p suffix can be ignored because the, say, mathematical number 0.1|1 can be easily stored in an IEEE double with 53 bits. > 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. In the case of exact numbers, this is a simple calculation with bigints and their binary representations; in the case of inexact numbers, an implementation can either apply `inexact' to exact numbers (as Chez does, for example) or the explicitly given mantissa width can be truncated at the maximum number of significant bits (which is 53 in the case of IEEE doubles). In fact, I have an implementation for Chez Scheme's reader that only needs a couple of lines. Marc PS Beginning with tomorrow, during the next ten days, I will only have sporadic access to email (and only limited time).
