If I recall, I took into account IEEE 754 round-to-even rules to make upper and lower bounds for the float value, noting which were inclusive and which exclusive. Then I used continued fraction ideas to generate digits left-to-right with no need for correction.
I never looked in detail at the papers which used fixed precision, to see if they would generate the same decimal representations that I did. A quick skim indicated that they were pretty careful. 🤞 > On Nov 14, 2023, at 6:54 AM, Bob Cassels <bobcass...@netscape.net> wrote: > > Yes, that’s the Steele (and JonL) paper I was thinking of. > > >> On Nov 13, 2023, at 2:16 AM, raymond.wi...@icloud.com wrote: >> >> “How to Print Floating-Point Numbers Accurately”, perhaps? >> >> https://lists.nongnu.org/archive/html/gcl-devel/2012-10/pdfkieTlklRzN.pdf >> >>> On 10 Nov 2023, at 12:37, bobcass...@netscape.net wrote: >>> >>> I did the Symbolics Lisp Machine implementation of floating point print. >>> Mine was completely accurate, using exact rational arithmetic with bignums. >>> But not very efficient. >>> >>> I have seen papers showing how to be accurate with fixed precision >>> arithmetic. It requires great care. I believe that some C or C++ >>> implementations use this procedure. So I would not be surprised if some >>> implementation of floating point printing is incorrect. >>> >>> I have a vague recollection of some paper by Guy Steele on the subject. I >>> recall using ideas from Bill Gosper's continued fraction work. >>> >>> >>> On Nov 10, 2023 5:39 AM, Marco Antoniotti <marco.antonio...@unimib.it> >>> wrote: >>> Thank you. >>> >>> I have not checked the details, but are you implying that clang printf >>> is... buggy? Knuth has such a caveat (about buggy printf implementations) >>> on his page. >>> >>> All the best >>> >>> Marco >>> >>> >>> On Fri, Nov 10, 2023 at 11:35 AM <raymond.wi...@icloud.com >>> <mailto:raymond.wi...@icloud.com>> wrote: >>> I think that clang is simply printing more information than it is allowed >>> (or supposed) to. For a double-precision IEEE754 float, the number of >>> significant digits should be >>> >>> (floor (* 54.0d0 (/ (log 2.0d0) (log 10.0d0)))) >>> >>> which evaluates to 16 (53-bit mantissa + 1 hidden digit). The Lisp output >>> has exactly 16 significant digits, while the clang output has 20. >>> >>> The actual correct digits seem to be >>> >>> (ash (expt 10 52) -52) >>> >>> which evaluates to >>> >>> 2220446049250313080847263336181640625. >>> >>> >>> >>> >>> >>> On 10 Nov 2023, at 09:55, Marco Antoniotti (as marco dot antoniotti at >>> unimib dot it) <lisp-...@lispworks.com <mailto:lisp-...@lispworks.com>> >>> wrote: >>> >>> Hi >>> >>> Thanks Pascal. >>> >>> For LW on Intel (Mac) the ULP seems the same. With SBCL you should >>> actually be able to peek at the actual bits making up the double float. >>> Can you do something similar with LM? >>> >>> Just curious: has anybody tried this on a M*/Arm Mac? Or, with LW, on your >>> smartphone? :) >>> >>> Cheers >>> >>> MA >>> >>> >>> On Fri, Nov 10, 2023 at 8:29 AM Pascal Bourguignon (as pjb at informatimago >>> dot com) <lisp-...@lispworks.com <mailto:lisp-...@lispworks.com>> wrote: >>> >>> >>> On 9 Nov 2023, at 21:21, Marco Antoniotti <marco.antonio...@unimib.it >>> <mailto:marco.antonio...@unimib.it>> wrote: >>> >>> <problem-loop.lisp> >>> >>> >>> From the start, it looks like the ulp is more precise in C: >>> >>> >>> sbcl: 2.220446049250313d-16 >>> clang: 2.2204460492503130808e-16 >>> >>> (using %.20g instead of %.20f) >>> >>> Or perhaps it’s only the display procedure that truncates in lisp? >>> >>> -- >>> __Pascal J. Bourguignon__ >>> >>> >>> >>> >>> >>> >> >
