[musl] accuracy of mathematical functions

[musl] accuracy of mathematical functions

[Paul Zimmermann]

       Hi,

I have updated my comparison with the newly released glibc-2.33 version.
No big difference with the previous version, except that I included
the "long double" format (aka ldbl-96), including for musl (see pages
13 and 15):

https://members.loria.fr/PZimmermann/papers/#accuracy

Best regards,
Paul

[musl] accuracy of mathematical functions

[Paul Zimmermann]

       Hi,

I am about to release a new update of the accuracy comparison of mathematical
functions [1]. It will mention Musl 1.2.2, the last release to date. The
following issues are still present in 1.2.2:

* acoshf and sinhf return a finite value instead of NaN (or the converse).
  Fixed by Szabolcs in February, but no new release since then.

* huge maximal errors for j0f, j1f, lgammaf, y0f, y1f

* huge maximal errors for j0, j1, lgamma, y0, y1

* large maximal known error for exp10l (40.1 ulps), expm1l (9.71e3 ulps),
  sinhl (9.71e3 ulps), powl (533 ulps), huge maximal known error for
  lgammal (9.08e19 ulps) and tgammal (3.69e19 ulps)

Best regards,
Paul

[1] https://members.loria.fr/PZimmermann/papers/accuracy.pdf

Re: [musl] accuracy of mathematical functions

[Morten Welinder]

* huge maximal errors for j0f, j1f, lgammaf, y0f, y1f

If anyone feels the urge to fix the bessel functions, the best
reference probably is John Harrison's:
https://www.cl.cam.ac.uk/~jrh13/papers/bessel.html  A certain amount
of tables will be needed, though.

M.

[musl] accuracy of mathematical functions

[Paul Zimmermann]

       Hi,

a new update is available:

https://members.loria.fr/PZimmermann/papers/#accuracy

It now considers Musl 1.2.2, and two new libraries: Apple and CUDA.

Best regards,
Paul Zimmermann

[musl] Accuracy of Mathematical Functions

[Paul Zimmermann]

       Hi,

we have updated our comparison:

https://members.loria.fr/PZimmermann/papers/accuracy.pdf

This update uses Musl 1.2.3. The acoshf and sinhf issues reported in 1.2.2
are fixed (thank you Szabolcs).

The main change is that the LLVM library now implements a few
correctly-rounded routines in single precision (log, log10, log2,
hypot), and hypot in double precision.

Best regards,
Paul

[musl] Accuracy of Mathematical Functions

[Paul Zimmermann]

       Hi,

we have updated our comparison:

https://members.loria.fr/PZimmermann/papers/accuracy.pdf

This update uses Musl 1.2.3 (same version as the last update in August 2022).

The main change is that the LLVM library now implements more
correctly-rounded routines in single precision.

Best regards,
Paul

[musl] Accuracy of Mathematical Functions

[Paul Zimmermann]

       Hi,

we have updated our comparison:

https://members.loria.fr/PZimmermann/papers/accuracy.pdf

This update uses Musl 1.2.4 (the previous one was for Musl 1.2.3).
The two reported issues in double-extended precision (end of page 15)
are already fixed in the development version (thanks Szabolcs).

This is a new version with updated versions of the different libraries and:

* the Microsoft math library is now included (it was clearly missing)
* we also added the FreeBSD math library
* and we added some new C23 functions (acospi, cospi, ...) which are available
  in the Intel and FreeBSD math libraries

Paul Zimmermann

Re: [musl] Accuracy of Mathematical Functions

[enh]

isn't Apple's libm (like Android's) largely the FreeBSD libm? are the
Apple vs FreeBSD differences you found really FreeBSD/arm64 vs
FreeBSD/x86-64 differences? (or differences between older and newer
FreeBSD libms?)

On Thu, Sep 21, 2023 at 12:31 AM Paul Zimmermann
<Paul.Zimmermann@inria.fr> wrote:
>
>        Hi,
>
> we have updated our comparison:
>
> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
>
> This update uses Musl 1.2.4 (the previous one was for Musl 1.2.3).
> The two reported issues in double-extended precision (end of page 15)
> are already fixed in the development version (thanks Szabolcs).
>
> This is a new version with updated versions of the different libraries and:
>
> * the Microsoft math library is now included (it was clearly missing)
> * we also added the FreeBSD math library
> * and we added some new C23 functions (acospi, cospi, ...) which are available
>   in the Intel and FreeBSD math libraries
>
> Paul Zimmermann

Re: [musl] Accuracy of Mathematical Functions

[Szabolcs Nagy]

* enh <enh@google.com> [2023-09-21 09:30:10 -0700]:
> isn't Apple's libm (like Android's) largely the FreeBSD libm? are the
> Apple vs FreeBSD differences you found really FreeBSD/arm64 vs
> FreeBSD/x86-64 differences? (or differences between older and newer
> FreeBSD libms?)

freebsd is mostly c so behaves the same on x86 and arm
(fma usage can be different but that's about it)

in the apple libm neither x86 nor arm version looks freebsd based
(and this is old, they likely updated it for aarch64)

https://opensource.apple.com/source/Libm/Libm-2026/Source/

Re: [musl] Accuracy of Mathematical Functions

[enh]

oh, interesting... i see a lot of the files in the arm directory have
freebsd in the name but, yes, even there the majority seems to be
home-grown code.

On Thu, Sep 21, 2023 at 11:44 PM Szabolcs Nagy <nsz@port70.net> wrote:
>
> * enh <enh@google.com> [2023-09-21 09:30:10 -0700]:
> > isn't Apple's libm (like Android's) largely the FreeBSD libm? are the
> > Apple vs FreeBSD differences you found really FreeBSD/arm64 vs
> > FreeBSD/x86-64 differences? (or differences between older and newer
> > FreeBSD libms?)
>
> freebsd is mostly c so behaves the same on x86 and arm
> (fma usage can be different but that's about it)
>
> in the apple libm neither x86 nor arm version looks freebsd based
> (and this is old, they likely updated it for aarch64)
>
> https://opensource.apple.com/source/Libm/Libm-2026/Source/
>

[musl] Accuracy of Mathematical Functions

[Paul Zimmermann]

       Dear all,

we have updated our comparison:

https://members.loria.fr/PZimmermann/papers/accuracy.pdf

This is a new version with updated versions of the different libraries, new corner
cases found, and the ARM Performance Library is now included.

There was no new release of Musl since our last update, thus it is still 1.2.4
that is tested.

Paul Zimmermann

[musl] Accuracy of Mathematical Functions

[Paul Zimmermann]

       Dear all,

we have updated our comparison with Musl 1.2.5:

https://members.loria.fr/PZimmermann/papers/accuracy.pdf

Large errors still there in 1.2.5:

* exp10l, expm1l, lgammal, sinhl, tgammal, powl

Paul

[musl] Accuracy of Mathematical Functions

[Paul Zimmermann]

       Dear all,

a new update of our comparison is available:

https://members.loria.fr/PZimmermann/papers/accuracy.pdf

Main changes in this update:

* GNU libc now provides 21 correctly-rounded functions in single precision
  (integrating the CORE-MATH code)
* LLVM-libc provides more correctly-rounded functions

No new issue for Musl was found.

Brian Gladman
Vincenzo Innocente
John Mather
Paul Zimmermann

[musl] Accuracy of Mathematical Functions

[Paul Zimmermann]

       Hi,

a new update of our comparison is available:

https://members.loria.fr/PZimmermann/papers/accuracy.pdf

Main changes in this update:

* we have added compoundn, pown and rootn
* GNU libc is the first library to provide all new C23 functions
* GNU libc now provides 31 correctly-rounded functions in single precision

As for Musl, since there was no new release since the last update, which was
using Musl 1.2.5, there are no changes.

Brian Gladman
Vincenzo Innocente
John Mather
Paul Zimmermann

[musl] Accuracy of Mathematical Functions

[Paul Zimmermann]

       Dear all,

a new update of our comparison is available, still with Musl 1.2.5:

https://members.loria.fr/PZimmermann/papers/accuracy.pdf

Main changes in this update:

* thanks to Katsuhisa Ozaki, we have updated to MSVC 2026, where several
  issues reported against MSVC 2022 have been fixed

* in double precision, for all C99 univariate functions, at least one library
  now provides a correctly-rounded version, except atan, cosh, sinh, tanh

Brian Gladman
Vincenzo Innocente
John Mather
Katsuhisa Ozaki
Paul Zimmermann

Re: [musl] Accuracy of Mathematical Functions

[Szabolcs Nagy]

* Paul Zimmermann <Paul.Zimmermann@inria.fr> [2026-02-14 08:34:42 +0100]:
>        Dear all,
> 
> a new update of our comparison is available, still with Musl 1.2.5:
> 
> https://members.loria.fr/PZimmermann/papers/accuracy.pdf

thanks.

> * in double precision, for all C99 univariate functions, at least one library
>   now provides a correctly-rounded version, except atan, cosh, sinh, tanh

do you have information on their code/rodata size
and worst-case latency/throughput?

i found
https://github.com/llvm/llvm-project/blob/main/libc/docs/headers/math/index.rst
but it does not seem to have numbers on double prec.

eventually it may be worth considering cr in libc.

Re: [musl] Accuracy of Mathematical Functions

[Paul Zimmermann]

       Hi Szabolcs,

> > * in double precision, for all C99 univariate functions, at least one library
> >   now provides a correctly-rounded version, except atan, cosh, sinh, tanh
> 
> do you have information on their code/rodata size
> and worst-case latency/throughput?
> 
> i found
> https://github.com/llvm/llvm-project/blob/main/libc/docs/headers/math/index.rst
> but it does not seem to have numbers on double prec.

from a GNU libc 2.43 build, which integrates atanh from CORE-MATH:

$ ls -l ./math/e_acosh.o
-rw-r--r-- 1 zimmerma caramba 57696 Jan 29 14:06 ./math/e_acosh.o

You can find some timings about the integration of acosh in GNU libc here:

https://sourceware.org/pipermail/libc-alpha/2025-October/170985.html

(there are similar timings for other functions integrated in GNU libc)

> eventually it may be worth considering cr in libc.

Best regards,
Paul

Re: [musl] Accuracy of Mathematical Functions

[Szabolcs Nagy]

* Paul Zimmermann <Paul.Zimmermann@inria.fr> [2026-02-15 09:18:49 +0100]:
> from a GNU libc 2.43 build, which integrates atanh from CORE-MATH:

ah, i missed this.
good work
thanks

> $ ls -l ./math/e_acosh.o
> -rw-r--r-- 1 zimmerma caramba 57696 Jan 29 14:06 ./math/e_acosh.o

you should use 'size' from binutils to see the
actual code size (or size -A to see .text and
.rodata separately), that's what matters at
runtime. writable data should be 0.

i think up to 4k lookup table is acceptable
per function, beyond that one can start to
worry about tiny vs fast tradeoffs.

> 
> You can find some timings about the integration of acosh in GNU libc here:
> 
> https://sourceware.org/pipermail/libc-alpha/2025-October/170985.html
> 
> (there are similar timings for other functions integrated in GNU libc)
> 
> > eventually it may be worth considering cr in libc.
> 
> Best regards,
> Paul

Re: [musl] Accuracy of Mathematical Functions

[Paul Zimmermann]

       Hi Szabolcs,

here is the result of size -A on the acosh code from GNU libc
(integrated from CORE-MATH):

$ size -A ./math/e_acosh.o
./math/e_acosh.o  :
section            size   addr
.text              4054      0
.data                 0      0
.bss                  0      0
.rodata            2656      0
.rodata.cst8        376      0
.rodata.cst16        16      0
.debug_info        8382      0
.debug_abbrev       818      0
.debug_loclists    9253      0
.debug_aranges       48      0
.debug_rnglists     819      0
.debug_line        3972      0
.debug_str          730      0
.debug_line_str     301      0
.comment             32      0
.note.GNU-stack       0      0
.eh_frame           240      0
Total             31697

Paul

> Date: Mon, 16 Feb 2026 01:03:42 +0100
> From: Szabolcs Nagy <nsz@port70.net>
> Cc: musl@lists.openwall.com
> 
> * Paul Zimmermann <Paul.Zimmermann@inria.fr> [2026-02-15 09:18:49 +0100]:
> > from a GNU libc 2.43 build, which integrates atanh from CORE-MATH:
> 
> ah, i missed this.
> good work
> thanks
> 
> > $ ls -l ./math/e_acosh.o
> > -rw-r--r-- 1 zimmerma caramba 57696 Jan 29 14:06 ./math/e_acosh.o
> 
> you should use 'size' from binutils to see the
> actual code size (or size -A to see .text and
> .rodata separately), that's what matters at
> runtime. writable data should be 0.
> 
> i think up to 4k lookup table is acceptable
> per function, beyond that one can start to
> worry about tiny vs fast tradeoffs.
> 
> > 
> > You can find some timings about the integration of acosh in GNU libc here:
> > 
> > https://sourceware.org/pipermail/libc-alpha/2025-October/170985.html
> > 
> > (there are similar timings for other functions integrated in GNU libc)
> > 
> > > eventually it may be worth considering cr in libc.
> > 
> > Best regards,
> > Paul
>