Am Do., 29. Aug. 2024 um 21:15 Uhr schrieb Will Clinger <[email protected] >:
> 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. > The only difference is that the paper gets rid of inexact numbers. But even in RnRS with inexact numbers, an inexact number object (being a result of interpreting a number literal or of some function) should approximate the actual exact number as best as possible. (If we allow an implementation to introduce arbitrary rounding errors when inexact number objects are involved, the whole discussion is moot.= >> 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. > Yes. I haven't read your paper recently but I guess, the method is probably similar. But note that such an inefficient method only has to be used when there is an explicit mantissa width. For the majority of cases where there is no explicitly given mantissa width, whatever existing fast algorithm can be used. That said, Chez Scheme always does a bigint calculation and only converts the final result to an IEEE double. While this may not be the fastest method, it is apparently efficient enough - at least for the Chez Scheme authors. > > 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? > The latter number literal specifies the best approximation of 999...784 with a binary mantissa of length 54. As the number needs exactly 54 binary digits (if I didn't do the calculation wrong, but you will know better), the latter number literal is the number 999...784. This number is now to be represented by an inexact number object. When inexact number objects have only 53 significant binary digits, the number 999...784 has to be represented by the best approximation with 53 significant binary digits. But such an approximation is described by the former number literal. As I haven't implemented an algorithm using floating point arithmetic where possible, I haven't checked the details (and subnormal numbers probably need extra considerations); you are probably the best person to point out pitfalls. > 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. > My remark should be seen in the context that (1) explicit mantissa widths are rare and that (2) Chez does not use a faster algorithm anyway. Marc
