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@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@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@lispworks.com wrote:

...

On 9 Nov 2023, at 21:21, Marco Antoniotti 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__