Yes, that’s the Steele (and JonL) paper I was thinking of.
> On Nov 13, 2023, at 2:16 AM, raymond.wiker(a)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, bobcassels(a)netscape.net wrote:
>>
>> I did the Symbolics Lisp Machine implementation of floating point print. Mine was completely accurate, using exact …
[View More]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.antoniotti(a)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.wiker(a)icloud.com <mailto:raymond.wiker@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-hug(a)lispworks.com <mailto:lisp-hug@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-hug(a)lispworks.com <mailto:lisp-hug@lispworks.com>> wrote:
>>
>>
>> On 9 Nov 2023, at 21:21, Marco Antoniotti <marco.antoniotti(a)unimib.it <mailto:marco.antoniotti@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__
>>
>>
>>
>>
>>
>>
>
[View Less]
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 …
[View More]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.wiker(a)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, bobcassels(a)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.antoniotti(a)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.wiker(a)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-hug(a)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-hug(a)lispworks.com> wrote:
>
>
>
> On 9 Nov 2023, at 21:21, Marco Antoniotti <marco.antoniotti(a)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__
>
>
>
>
>
>
>
>
[View Less]
Dear all,
I am hitting a wall with the attached code in CL and C versions. For those
interested, this is code lifted from Knuth's pages on random number
generation (https://www-cs-faculty.stanford.edu/~knuth/programs.html#rng).
The problem is that there is a discrepancy in the "problem" loop between
the CL and the C and I cannot figure out why, although the culprit may be
that CL does not have "proper" 64 bits ints.
I am running on LW 8.x on an Intel Mac. I have not tried on other CL
…
[View More]implementations/platforms. I compile the C code with clang (Apple clang
version 15.0.0 (clang-1500.0.40.1)
If you run the code, you will see that the discrepancy appears at 'j = 14'
in the loop.
What gives?
Thanks
Marco
--
Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY
[View Less]
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.wiker(a)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) …
[View More](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-hug(a)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-hug(a)lispworks.com> wrote:
>
>>
>>
>> On 9 Nov 2023, at 21:21, Marco Antoniotti <marco.antoniotti(a)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__
>>
>>
>>
>>
>>
>
[View Less]
Thanks.
This is weird. The C and Fortran versions seem to agree.
Marco
On Thu, Nov 9, 2023 at 9:49 PM Frank Gönninger | Gönninger B&T <
frank.goenninger(a)goenninger.net> wrote:
> Hi Marco,
>
>
>
> on AllegroCL 11.0 beta Enterprise Edition I get diverging results starting
> at j = 21…
>
>
>
> Lisp: j = 21; ss = 0.00028959847986698150
>
> C: j = 21; ss = 0.00028959847986698151
>
>
>
> FWIW …
>
>
>
> Best,
>
…
[View More]> Frank
>
>
>
> *Von: *<owner-lisp-hug(a)lispworks.com> im Auftrag von "Marco Antoniotti
> (as marco dot antoniotti at unimib dot it)" <lisp-hug(a)lispworks.com>
> *Antworten an: *Marco Antoniotti <marco.antoniotti(a)unimib.it>
> *Datum: *Donnerstag, 9. November 2023 um 21:23
> *An: *LispWorks <lisp-hug(a)lispworks.com>, Discussion list for Common Lisp
> professionals <pro(a)common-lisp.net>
> *Betreff: *Help with bit bashing code: differences between C and CL
>
>
>
> Dear all,
>
>
>
> I am hitting a wall with the attached code in CL and C versions. For
> those interested, this is code lifted from Knuth's pages on random number
> generation (https://www-cs-faculty.stanford.edu/~knuth/programs.html#rng).
>
> The problem is that there is a discrepancy in the "problem" loop between
> the CL and the C and I cannot figure out why, although the culprit may be
> that CL does not have "proper" 64 bits ints.
>
> I am running on LW 8.x on an Intel Mac. I have not tried on other CL
> implementations/platforms. I compile the C code with clang (Apple clang
> version 15.0.0 (clang-1500.0.40.1)
>
>
>
> If you run the code, you will see that the discrepancy appears at 'j = 14'
> in the loop.
>
>
>
> What gives?
>
> Thanks
>
> Marco
>
>
>
>
>
>
> --
>
> Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01
> DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it
> Viale Sarca 336
> I-20126 Milan (MI) ITALY
>
[View Less]