largest known errors

[Paul Zimmermann]

       Hi Joseph,

> Date: Wed, 13 Dec 2023 21:40:04 +0000
> From: Joseph Myers <joseph@codesourcery.com>
> CC: Paul Zimmermann <Paul.Zimmermann@inria.fr>, <libc-alpha@sourceware.org>
> 
> On Wed, 13 Dec 2023, Carlos O'Donell wrote:
> 
> > There are two issues here and the nuances around them matter to me.
> > 
> > (a) There are known defects where ULPs may reach values that are not useful
> >     for talking about the library in general.
> > 
> > (b) There is value in being clear about the worst case known ULPs for an
> >     implementation of a given algorithm.
> > 
> > If a test is marked as XFAIL then it is clearly (a) and listing that worst
> > case ULPs in the manual may not be useful.
> > 
> > If the test is not marked as XFAIL then it is clearly in (b) and we should
> > list it in the manual as the worst case known ULPS because that is what
> > the currently implemented algorithm does.
> > 
> > Lastly, all XFAIL entries should reference bugs in our bug tracker, and
> > if they don't then we should create them to track and resolve the bug.
> 
> Also, a huge table by architecture (when many libm-test-ulps files may not 
> get reliably updated) may not be the most helpful way of presenting this 
> information.
> 
> In most case, it might be better for libm-test-ulps data to be by 
> floating-point format (rather than type; for the narrowing functions, 
> there are two formats involved, but ulps should be zero for those 
> everywhere except when narrowing from IBM long double), but shared between 
> architectures.  Although there are some architecture-specific 
> implementations and variation between architectures for results (because 
> of different implementations, variation in whether fma gets contracted, 
> etc.), there aren't so many such variations (especially once we remove 
> ia64), and listing the maximum ulps expected for a function for a given 
> format might be better than trying to track architecture-specific values 
> (just as we got rid of ulps entries for individual test inputs a long time 
> ago).  If we made that change, maybe the vector function ulps would still 
> sensibly be architecture-specific; and initial entries for an 
> architecture-independent libm-test-ulps file might better be determined by 
> what ulps actually appear on a few architectures than by taking the 
> maximum across existing libm-test-ulps files, many of which are not 
> well-maintained.

that would indeed simplify the presentation, but we still need to find a way
to give accurate information to the user.

I've filled a bug (PR #31165) so that we can keep track of this issue.

Paul