Thank you Martin.
Meanwhile, I fell in a rabbit hole (your fault guys!) and I produced this thing. I am sure it is code that has been written a godzillion times before. I will use it for the next phase of debugging.
Please poke holes into it.
All the best
Marco
On Fri, Nov 10, 2023 at 2:45 PM Martin Simmons martin@lispworks.com wrote:
Actually, ULP is not the same on LispWorks, which is why it diverges at 14. You can't see it when printing 20 decimal places.
The reason is that LispWorks calculates (expt 2.0d0 -52) using natural logarithms, so loses a few bits of precision. If you change it to use (/ 1d0 (ash 1 30) (ash 1 22)) or (float (expt 2 -52) 1d0) then LispWorks also appears to diverge at 21 like on other Lisps.
Looking at the binary representation of the floats shows that this divergence at 21 is just in the printing. The C library prints some extra digits that are not needed.
-- Martin Simmons LispWorks Ltd http://www.lispworks.com/
On Fri, 10 Nov 2023 09:55:38 +0100, Marco Antoniotti said:
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__
Lisp Hug - the mailing list for LispWorks users lisp-hug@lispworks.com http://www.lispworks.com/support/lisp-hug.html