Thank you Raymond. Yes I am aware of the paper and of the vagaries of printing floats FROM binary. I was, at this point, going in the reverse: printing the binary representation of a float.
Having said that, I love the sentence in the paper "we did not think it was such a big deal". It looks like it still is 🙄 Also, an ode to Common Lisp (preaching to the choir): the code I wrote is, IMHO, somewhat more portable than the C versions I saw around, thanks to all the float introspection functions and the (let's say it! underdocumented) DECODE-FLOAT and INTEGER-DECODE-FLOAT functions. All the best Marco On Mon, Nov 13, 2023 at 8:17 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> 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> 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> wrote: > > > > On 9 Nov 2023, at 21:21, Marco Antoniotti <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__ > > > > > > > >
