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__
>>
>>
>>
>>
>>
>