accuracy of mathematical functions

accuracy of mathematical functions

[Paul Zimmermann]

       Hi,

I have updated my comparison with the newly released 2.33 version.
No big difference with the previous version, except that I included
the "long double" format (aka ldbl-96), which is not supported by Newlib.

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

Best regards,
Paul

Re: accuracy of mathematical functions

[Brian Inglis]

On 2021-02-05 03:43, Paul Zimmermann wrote:
> I have updated my comparison with the newly released 2.33 version.
> No big difference with the previous version, except that I included
> the "long double" format (aka ldbl-96), which is not supported by Newlib.
> 
> https://members.loria.fr/PZimmermann/papers/#accuracy

Thanks for doing this work and making it available is greatly appreciated.

While newlib is mainly targeted to smaller platforms, the Cygwin port math 
library supports gcc __FLT64X_...__/__FLT128_...__ under
.../newlib-cygwin/winsup/cygwin/math/ and related includes.

As you may already be aware, clang and gcc have added support for ARM 
__FLT16/__fp16, AMD and Intel have added it to x86/amd64 as CVT16/FP16C 
https://en.wikipedia.org/wiki/F16C, and more compiler and library support are 
likely to follow, as they are already used in graphics and GPGPU areas.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

[Shame your CORE-Math proposal was rejected: desperately needed these days, as 
I've never been a math natural but often seemed more comfortable than other 
programmers doing related work.
Maybe have to comb the literature on reproducible builds, need for verification 
no backdoors or vulnerabilities have been introduced, and testing results 
produced are identical across platforms; maybe comb Risks or contact PGN for 
math horror stories as references and justifications for resubmission.]

Re: accuracy of mathematical functions

[Joel Sherrill]

On Fri, Feb 5, 2021 at 5:01 PM Brian Inglis <Brian.Inglis@systematicsw.ab.ca>
wrote:

> On 2021-02-05 03:43, Paul Zimmermann wrote:
> > I have updated my comparison with the newly released 2.33 version.
> > No big difference with the previous version, except that I included
> > the "long double" format (aka ldbl-96), which is not supported by Newlib.
> >
> > https://members.loria.fr/PZimmermann/papers/#accuracy
>
> Thanks for doing this work and making it available is greatly appreciated.
>
> While newlib is mainly targeted to smaller platforms, the Cygwin port math
> library supports gcc __FLT64X_...__/__FLT128_...__ under
> .../newlib-cygwin/winsup/cygwin/math/ and related includes.
>

Any thoughts on what's required to have long double support on the targets
where long double != double? Someone was recently cleaning up the warnings
from the RTEMS tests which check that the headers match POSIX's man page
and I generated this list of architectures from the RTEMS tools and which
have
long double support in libm.a

no aarch64-rtems6
yes arm-rtems6
yes bfin-rtems6
no i386-rtems6
yes lm32-rtems6
no m68k-rtems6
yes microblaze-rtems6
yes mips-rtems6
yes moxie-rtems6
yes nios2-rtems6
yes or1k-rtems6
yes powerpc-rtems6
no riscv-rtems6
yes sh-rtems6
no sparc64-rtems6
yes sparc-rtems6
yes v850-rtems6
no x86_64-rtems6

It probably is a decent GSoC project if upstream sources for long double
on some of those architectures can be identified for potential
incorporation.


>
> As you may already be aware, clang and gcc have added support for ARM
> __FLT16/__fp16, AMD and Intel have added it to x86/amd64 as CVT16/FP16C
> https://en.wikipedia.org/wiki/F16C, and more compiler and library support
> are
> likely to follow, as they are already used in graphics and GPGPU areas.
>

What would this require from newlib, if anything?  He asks ignorantly. :)

--joel


> --
> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
>
> This email may be disturbing to some readers as it contains
> too much technical detail. Reader discretion is advised.
> [Data in binary units and prefixes, physical quantities in SI.]
>
> [Shame your CORE-Math proposal was rejected: desperately needed these
> days, as
> I've never been a math natural but often seemed more comfortable than
> other
> programmers doing related work.
> Maybe have to comb the literature on reproducible builds, need for
> verification
> no backdoors or vulnerabilities have been introduced, and testing results
> produced are identical across platforms; maybe comb Risks or contact PGN
> for
> math horror stories as references and justifications for resubmission.]
>

Re: accuracy of mathematical functions

[Brian Inglis]

On 2021-02-05 16:46, Joel Sherrill wrote:
> On Fri, Feb 5, 2021 at 5:01 PM Brian Inglis wrote:
>> On 2021-02-05 03:43, Paul Zimmermann wrote:
>>> I have updated my comparison with the newly released 2.33 version.
>>> No big difference with the previous version, except that I included
>>> the "long double" format (aka ldbl-96), which is not supported by Newlib.
>>>
>>> https://members.loria.fr/PZimmermann/papers/#accuracy
>>
>> Thanks for doing this work and making it available is greatly appreciated.
>>
>> While newlib is mainly targeted to smaller platforms, the Cygwin port math
>> library supports gcc __FLT64X_...__/__FLT128_...__ under
>> .../newlib-cygwin/winsup/cygwin/math/ and related includes.

> Any thoughts on what's required to have long double support on the targets 
> where long double != double? Someone was recently cleaning up the warnings 
> from the RTEMS tests which check that the headers match POSIX's man page and
> I generated this list of architectures from the RTEMS tools and which have 
> long double support in libm.a
> 
> no  aarch64-rtems6
> yes arm-rtems6
> yes bfin-rtems6
> no  i386-rtems6
> yes lm32-rtems6
> no  m68k-rtems6
> yes microblaze-rtems6
> yes mips-rtems6
> yes moxie-rtems6
> yes nios2-rtems6
> yes or1k-rtems6
> yes powerpc-rtems6
> no  riscv-rtems6
> yes sh-rtems6
> no  sparc64-rtems6
> yes sparc-rtems6
> yes v850-rtems6
> no  x86_64-rtems6
> 
> It probably is a decent GSoC project if upstream sources for long double on
> some of those architectures can be identified for potential incorporation.
ARM aarch64 probably have c and S sources available, maybe recent PowerPC.

Cygwin sources appear to be from mingw-w64 and are PD, ZPL, or unspecified:

$cd ~/src/newlib-cygwin/winsup/cygwin/math/
$ egrep -c 'Zope|PD' *l.* | pr -4th ""
acoshl.c:1        complex_internal. floorl.S:1        nearbyintl.S:1
acosl.c:1         conjl.c:1         fmal.c:1          nextafterl.c:1
asinhl.c:1        copysignl.S:1     fmaxl.c:1         pow10l.c:0
asinl.c:1         coshl.c:1         fminl.c:1         powil.c:1
atan2l.c:1        cosl.c:1          fmodl.c:1         powl.c:1
atanhl.c:1        cosl_internal.S:1 frexpl.S:1        remainderl.S:1
atanl.c:1         cpowl.c:1         ilogbl.S:1        remquol.S:1
cabsl.c:1         cprojl.c:1        internal_logl.S:1 rintl.c:1
cacosl.c:1        creal.def.h:1     ldexpl.c:1        roundl.c:1
cargl.c:1         creall.c:1        lgammal.c:1       scalbl.S:1
casinl.c:1        csinl.c:1         llrintl.c:1       scalbnl.S:1
catanl.c:1        csqrtl.c:1        llroundl.c:1      sinhl.c:1
cbrtl.c:1         ctanl.c:1         log10l.S:1        sinl.c:1
ccosl.c:1         erfl.c:1          log1pl.S:1        sinl_internal.S:1
ceil.S:1          exp10l.c:0        log2l.S:1         sqrtl.c:1
ceill.S:1         exp2l.S:1         logbl.c:1         tanhl.c:1
cexpl.c:1         expl.c:1          logl.c:1          tanl.S:1
cimagl.c:1        expm1l.c:1        lrintl.c:1        tgammal.c:1
clog10l.c:1       fabsl.c:1         lroundl.c:1       truncl.c:1
clogl.c:1         fdiml.c:1         modfl.c:1
$ head ???10l.c
==> exp10l.c <==
#undef exp10l
#include <math.h>

long double
exp10l (long double x)
{
   return powl (10.0L, x);
}

==> pow10l.c <==
#undef pow10l
#include <math.h>

long double
pow10l (long double x)
{
   return powl (10.0L, x);
}

>> As you may already be aware, clang and gcc have added support for ARM 
>> __FLT16/__fp16, AMD and Intel have added it to x86/amd64 as CVT16/FP16C 
>> https://en.wikipedia.org/wiki/F16C, and more compiler and library support 
>> are likely to follow, as they are already used in graphics and GPGPU
>> areas.
> 
> What would this require from newlib, if anything?  He asks ignorantly. :)

More of a comment to the OP for future exhaustive testing.

Indication of demand or need; arch and compiler support; adopt/adapt software 
library?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: accuracy of mathematical functions

[Paul Zimmermann]

       Dear Brian,

> > I have updated my comparison with the newly released 2.33 version.
> > No big difference with the previous version, except that I included
> > the "long double" format (aka ldbl-96), which is not supported by Newlib.
> > 
> > https://members.loria.fr/PZimmermann/papers/#accuracy
> 
> Thanks for doing this work and making it available is greatly appreciated.

thank you.

> While newlib is mainly targeted to smaller platforms, the Cygwin port math 
> library supports gcc __FLT64X_...__/__FLT128_...__ under
> .../newlib-cygwin/winsup/cygwin/math/ and related includes.

how to get them in libm.a? For example I get only 'ctanhl' available,
but not 'tanhl':

$ nm libm.a | grep tanhl
lib_a-atanhl.o:
lib_a-catanhl.o:
0000000000000000 T catanhl
lib_a-ctanhl.o:
0000000000000000 T ctanhl
lib_a-tanhl.o:

> As you may already be aware, clang and gcc have added support for ARM 
> __FLT16/__fp16, AMD and Intel have added it to x86/amd64 as CVT16/FP16C 
> https://en.wikipedia.org/wiki/F16C, and more compiler and library support are 
> likely to follow, as they are already used in graphics and GPGPU areas.

thank you, if/when they are available in libraries, I will extend my comparison
to those formats.

Best regards,
Paul

accuracy of mathematical functions

[Paul Zimmermann]

       Hi,

I am about to publish a new version of the comparison of the accuracy of
mathematical functions. This new version will be co-authored with Vincenzo
Innocente and will include two new libraries: Apple Libm and CUDA.

I take the opportunity to check the following issues, which seem to be still
present in the last release (4.1.0) of Newlib that we will use in that update:

* large error for powf (169 ulps)

* sqrtf not correctly rounded for directed rounding modes -> fixed in git version

* large error for pow in double precision (636 ulps)

Are some of these issues fixed in the git version, or are there plans to fix
them?

Best regards,
Paul

PS: the previous version (already with 4.1.0) is available here:
https://members.loria.fr/PZimmermann/papers/accuracy.pdf

accuracy of mathematical functions

[Paul Zimmermann]

       Hi,

a new version is available, co-authored with Vincenzo Innocente:

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

There was no new release of Newlib since the last update (the last
release is still 4.1.0), but for some functions we have found larger
errors (for example for binary64 expm1 the maximal error increased
from 0.902 to 0.907 ulps).

This update includes two new libraries: Apple and CUDA.

Best regards,
Paul Zimmermann

Accuracy of Mathematical Functions

[Paul Zimmermann]

       Hi,

we have updated our comparison with Newlib 4.2.0:

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

There is not much change with respect to 4.1.0, only
larger errors for expf, tgammaf and lgammaf, but this
is due to a bug in our testing program, which did not
report those values before.

New libraries are compared: LLVM and ROCm.

Paul Zimmermann

Accuracy of Mathematical Functions

[Paul Zimmermann]

       Hi,

we have updated our comparison:

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

This update uses the same release of Newlib (4.2.0) as the previous one,
thus there is no much new for Newlib. The single precision issues are still
there (see "Notes about Newlib" on page 3).

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

Accuracy of Mathematical Functions

[Paul Zimmermann]

       Hi,

we have updated our comparison:

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

This update uses the new release of Newlib (4.3.0). for which we noticed some
regressions (already reported on this list).

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

Best regards,
Paul

Accuracy of Mathematical Functions

[Paul Zimmermann]

       Hi,

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

This version uses the same Newlib version (4.3.0) as the previous one,
thus there is no much change for Newlib.

In particular the regression for tgammaf I reported on February 8 is still
there:

https://sourceware.org/pipermail/newlib/2023/020171.html

Same for the huge error in pow reported on February 7:

https://sourceware.org/pipermail/newlib/2023/020164.html

Corinna, since you asked, a correctly rounded version is available here:

https://gitlab.inria.fr/core-math/core-math/-/blob/master/src/binary64/pow/pow.c

Best regards,
Paul Zimmermann

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, in particular
from Newlib 4.3.0 to 4.4.0, new corner cases found, and the ARM Performance Library
is now included.

Paul Zimmermann