Re: [PATCH] Fix the inaccuracy of j0f (BZ 14469) and y0f (BZ 14471) [v2]

[Joseph Myers <joseph@codesourcery.com>]

On Fri, 22 Jan 2021, Adhemerval Zanella wrote:

> On 22/01/2021 11:23, Paul Zimmermann wrote:
> >        Dear Adhemerval,
> > 
> >> Paul, besides mixed indentation and other style issues (which should
> >> be easier to fix, I can help you out with this), I am seeing these failures
> >> on a x86_64 with 9.2.1: [...]
> > 
> > these failures are due to the inputs that now give the largest error in
> > binary32, rounding to nearest, because I've added those inputs to
> > math/auto-libm-test-in.
> > 
> > For math/test-float-j0 and math/test-float-y0, it appears those inputs
> > give an error larger than 9 ulps for some directed rounding modes.
> > 
> > For other failures, it appears those inputs, when converted to other
> > formats, also give errors larger than 9 ulps.
> > 
> > Should I remove those inputs from auto-libm-test-in?
> 
> So if I understand correctly, you patch increase the ulps for non-default
> rounding for this specific inputs? If it were the case, could be fix it
> as well? 

The 9ulp limit applies to all rounding modes; implementations that don't 
go over that limit in any rounding mode are certainly best.  (In some 
cases SET_RESTORE_ROUNDF (FE_TONEAREST) (for float; different macro names 
for different types) can be used as a cheap way to reduce errors in other 
rounding modes, but then in general you need to take care about 
recomputing some overflowing / underflowing results in the original 
rounding mode.)

It's a good idea to test any patch adding inputs to auto-libm-test-in for 
all floating-point formats supported by glibc, to make sure large errors 
aren't introduced for other formats.  That means testing on at least two 
architectures (because ldbl-128ibm is only supported on powerpc, and 
ldbl-96 is only supported on x86_64/i386/ia64).  In all cases, the patch 
as submitted needs to be tested on at least one architecture to make sure 
it does not introduce any test failures there (and in particular, that 
there are no too-large ulps on that architecture after the patch for any 
non-XFAILed input in auto-libm-test-in).

If you don't want to fix all implementations at once for a given input in 
auto-libm-test-in, you can use xfail:<format> or xfail-rounding:<format>, 
e.g. xfail:binary128.  Such an XFAIL, for cases where errors are too large 
for some formats, should have a comment referencing an open bug for that 
issue of large errors (for Bessel functions, such bugs are already open in 
Bugzilla, since we can consider the open bugs to cover all affected 
formats).

-- 
Joseph S. Myers
joseph@codesourcery.com