Re: largest known errors

[Joseph Myers <joseph@codesourcery.com>]

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.

-- 
Joseph S. Myers
joseph@codesourcery.com