public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
* Accuracy of Mathematical Functions
@ 2022-08-29 10:50 Paul Zimmermann
  0 siblings, 0 replies; 9+ messages in thread
From: Paul Zimmermann @ 2022-08-29 10:50 UTC (permalink / raw)
  To: newlib; +Cc: vincenzo.innocente

       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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Accuracy of Mathematical Functions
@ 2022-02-16  8:42 Paul Zimmermann
  0 siblings, 0 replies; 9+ messages in thread
From: Paul Zimmermann @ 2022-02-16  8:42 UTC (permalink / raw)
  To: newlib; +Cc: vincenzo.innocente

       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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* accuracy of mathematical functions
@ 2021-09-07 15:01 Paul Zimmermann
  0 siblings, 0 replies; 9+ messages in thread
From: Paul Zimmermann @ 2021-09-07 15:01 UTC (permalink / raw)
  To: newlib

       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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* accuracy of mathematical functions
@ 2021-08-03  7:59 Paul Zimmermann
  0 siblings, 0 replies; 9+ messages in thread
From: Paul Zimmermann @ 2021-08-03  7:59 UTC (permalink / raw)
  To: newlib

       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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: accuracy of mathematical functions
  2021-02-05 23:01 ` Brian Inglis
  2021-02-05 23:46   ` Joel Sherrill
@ 2021-02-06  6:23   ` Paul Zimmermann
  1 sibling, 0 replies; 9+ messages in thread
From: Paul Zimmermann @ 2021-02-06  6:23 UTC (permalink / raw)
  To: newlib; +Cc: newlib

       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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: accuracy of mathematical functions
  2021-02-05 23:46   ` Joel Sherrill
@ 2021-02-06  0:40     ` Brian Inglis
  0 siblings, 0 replies; 9+ messages in thread
From: Brian Inglis @ 2021-02-06  0:40 UTC (permalink / raw)
  To: newlib

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: accuracy of mathematical functions
  2021-02-05 23:01 ` Brian Inglis
@ 2021-02-05 23:46   ` Joel Sherrill
  2021-02-06  0:40     ` Brian Inglis
  2021-02-06  6:23   ` Paul Zimmermann
  1 sibling, 1 reply; 9+ messages in thread
From: Joel Sherrill @ 2021-02-05 23:46 UTC (permalink / raw)
  To: Newlib

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: accuracy of mathematical functions
  2021-02-05 10:43 Paul Zimmermann
@ 2021-02-05 23:01 ` Brian Inglis
  2021-02-05 23:46   ` Joel Sherrill
  2021-02-06  6:23   ` Paul Zimmermann
  0 siblings, 2 replies; 9+ messages in thread
From: Brian Inglis @ 2021-02-05 23:01 UTC (permalink / raw)
  To: newlib

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* accuracy of mathematical functions
@ 2021-02-05 10:43 Paul Zimmermann
  2021-02-05 23:01 ` Brian Inglis
  0 siblings, 1 reply; 9+ messages in thread
From: Paul Zimmermann @ 2021-02-05 10:43 UTC (permalink / raw)
  To: newlib

       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

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2022-08-29 10:50 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-29 10:50 Accuracy of Mathematical Functions Paul Zimmermann
  -- strict thread matches above, loose matches on Subject: below --
2022-02-16  8:42 Paul Zimmermann
2021-09-07 15:01 accuracy of mathematical functions Paul Zimmermann
2021-08-03  7:59 Paul Zimmermann
2021-02-05 10:43 Paul Zimmermann
2021-02-05 23:01 ` Brian Inglis
2021-02-05 23:46   ` Joel Sherrill
2021-02-06  0:40     ` Brian Inglis
2021-02-06  6:23   ` Paul Zimmermann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).