math: Add more input to atanh accuracy tests

  This patch adds following input to atanh accuracy test.

    0x1.f80094p-8

Tested on x86-64 and i686 platforms.
Other platforms may have to regenerate ulps file.
---
 math/auto-libm-test-in        |  2 ++
 math/auto-libm-test-out-atanh | 25 +++++++++++++++++++++++++
 2 files changed, 27 insertions(+)
  

Dear Sunil,

> +# the next value generates larger error bounds on x86_64 (binary32)
> +atanh 0x1.f80094p-8

I only find a error of 0.598 ulp, whereas the largest error for binary32
is obtained for 0x1.ec2dd8p-4 (1.73 ulp). More precisely for x=0x1.f80094p-8
glibc 2.35 returns 0x1.f8031ep-8 (x86_64, skylake). Do you get a different value?
Maybe you used different CFLAGS than the default ones?

Best regards,
Paul
  

Hi Paul,

I got an optimization patch for function _ZGVeN16v_atanhf_skx. As a result of
optimization, ulps for(input 0x1.f80094p-8)  jumped from ~1.4 to ~2.4 and none
of the existing glibc atanh input catches it.

Currently at glibc master I am getting the following result.

Test: atanh_vlen16 (0x1.f80094p-8)
Result: 0x1.f80322p-8

I also tried input 0x1.ec2dd8p-4 but it doesn't catch the optimization accuracy
error jump for the proposed patch.

Thanks,
Sunil


On Tue, Feb 15, 2022 at 11:43 PM Paul Zimmermann
<Paul.Zimmermann@inria.fr> wrote:
>
>        Dear Sunil,
>
> > +# the next value generates larger error bounds on x86_64 (binary32)
> > +atanh 0x1.f80094p-8
>
> I only find a error of 0.598 ulp, whereas the largest error for binary32
> is obtained for 0x1.ec2dd8p-4 (1.73 ulp). More precisely for x=0x1.f80094p-8
> glibc 2.35 returns 0x1.f8031ep-8 (x86_64, skylake). Do you get a different value?
> Maybe you used different CFLAGS than the default ones?
>
> Best regards,
> Paul
  

Dear Sunil,

here is what I get with glibc master (b98d0bb):

$ LIBMVEC=512 GLIBC=glibc ./doit.libmvec atanh
LIBMVEC=512 -mavx512f
00000000004148f0 T mpfr_atanh
0000000000401668 t mpfr_atanh.cold
                 U _ZGVeN16v_atanhf@GLIBC_2.35
Checking atanh with libmvec from glibc and rndn
Sat 19 Feb 2022 04:48:53 AM CET
MPFR library: 4.1.0
MPFR header:  4.1.0 (based on 4.1.0)
Checking function atanhf with MPFR_RNDN
libm wrong by up to 1.45e+00 ulp(s) [1] for x=0x1.f2100ap-9
atanh      gives 0x1.f210aap-9
mpfr_atanh gives 0x1.f210a8p-9
Total: errors=58600734 (1.37%) errors2=0 maxerr=1.45e+00 ulp(s)

The maximal error is still 1.45 ulps.

Anyway, I guess the comment in auto-libm-test-in should say this is for
libmvec, and with -avx512.

Paul

> From: Sunil Pandey <skpgkp2@gmail.com>
> Date: Wed, 16 Feb 2022 10:40:06 -0800
> Cc: GNU C Library <libc-alpha@sourceware.org>
> 
> Hi Paul,
> 
> I got an optimization patch for function _ZGVeN16v_atanhf_skx. As a result of
> optimization, ulps for(input 0x1.f80094p-8)  jumped from ~1.4 to ~2.4 and none
> of the existing glibc atanh input catches it.
> 
> Currently at glibc master I am getting the following result.
> 
> Test: atanh_vlen16 (0x1.f80094p-8)
> Result: 0x1.f80322p-8
> 
> I also tried input 0x1.ec2dd8p-4 but it doesn't catch the optimization accuracy
> error jump for the proposed patch.
> 
> Thanks,
> Sunil
> 
> 
> On Tue, Feb 15, 2022 at 11:43 PM Paul Zimmermann
> <Paul.Zimmermann@inria.fr> wrote:
> >
> >        Dear Sunil,
> >
> > > +# the next value generates larger error bounds on x86_64 (binary32)
> > > +atanh 0x1.f80094p-8
> >
> > I only find a error of 0.598 ulp, whereas the largest error for binary32
> > is obtained for 0x1.ec2dd8p-4 (1.73 ulp). More precisely for x=0x1.f80094p-8
> > glibc 2.35 returns 0x1.f8031ep-8 (x86_64, skylake). Do you get a different value?
> > Maybe you used different CFLAGS than the default ones?
> >
> > Best regards,
> > Paul
>
  

On Fri, Feb 18, 2022 at 8:01 PM Paul Zimmermann
<Paul.Zimmermann@inria.fr> wrote:
>
>        Dear Sunil,
>
> here is what I get with glibc master (b98d0bb):
>
> $ LIBMVEC=512 GLIBC=glibc ./doit.libmvec atanh
> LIBMVEC=512 -mavx512f
> 00000000004148f0 T mpfr_atanh
> 0000000000401668 t mpfr_atanh.cold
>                  U _ZGVeN16v_atanhf@GLIBC_2.35
> Checking atanh with libmvec from glibc and rndn
> Sat 19 Feb 2022 04:48:53 AM CET
> MPFR library: 4.1.0
> MPFR header:  4.1.0 (based on 4.1.0)
> Checking function atanhf with MPFR_RNDN
> libm wrong by up to 1.45e+00 ulp(s) [1] for x=0x1.f2100ap-9
> atanh      gives 0x1.f210aap-9
> mpfr_atanh gives 0x1.f210a8p-9
> Total: errors=58600734 (1.37%) errors2=0 maxerr=1.45e+00 ulp(s)
>
> The maximal error is still 1.45 ulps.
>
> Anyway, I guess the comment in auto-libm-test-in should say this is for
> libmvec, and with -avx512.

Comment fixed in v2.

>
> Paul
>
> > From: Sunil Pandey <skpgkp2@gmail.com>
> > Date: Wed, 16 Feb 2022 10:40:06 -0800
> > Cc: GNU C Library <libc-alpha@sourceware.org>
> >
> > Hi Paul,
> >
> > I got an optimization patch for function _ZGVeN16v_atanhf_skx. As a result of
> > optimization, ulps for(input 0x1.f80094p-8)  jumped from ~1.4 to ~2.4 and none
> > of the existing glibc atanh input catches it.
> >
> > Currently at glibc master I am getting the following result.
> >
> > Test: atanh_vlen16 (0x1.f80094p-8)
> > Result: 0x1.f80322p-8
> >
> > I also tried input 0x1.ec2dd8p-4 but it doesn't catch the optimization accuracy
> > error jump for the proposed patch.
> >
> > Thanks,
> > Sunil
> >
> >
> > On Tue, Feb 15, 2022 at 11:43 PM Paul Zimmermann
> > <Paul.Zimmermann@inria.fr> wrote:
> > >
> > >        Dear Sunil,
> > >
> > > > +# the next value generates larger error bounds on x86_64 (binary32)
> > > > +atanh 0x1.f80094p-8
> > >
> > > I only find a error of 0.598 ulp, whereas the largest error for binary32
> > > is obtained for 0x1.ec2dd8p-4 (1.73 ulp). More precisely for x=0x1.f80094p-8
> > > glibc 2.35 returns 0x1.f8031ep-8 (x86_64, skylake). Do you get a different value?
> > > Maybe you used different CFLAGS than the default ones?
> > >
> > > Best regards,
> > > Paul
> >