[PATCH] math: Refactor how to use libm-test-ulps

[Joseph Myers]

On Mon, 27 Jan 2025, Adhemerval Zanella wrote:

> Regressions are only reported if the implementation shows larger errors
> than 9 ulps (13 for IBM long double) unless it is overridden by
> libm-test-ulps and the maximum error is not printed at the end of tests.
> The regen-ulps rule is also removed since it does not make sense to
> update the libm-test-ulps automatically.

I think the tests *should* report the maximum observed error for each 
function, even when it's not causing the tests to fail, to make it easy to 
see which functions have the largest errors.  (For example, say we wished 
to reduce the maximum error accepted from 9 ulps to something smaller.  
It's desirable to have a quick way to check, by running the tests for a 
target, which functions would need improving.)

> +math testsuite only flag results larger than 9ulp (or 16 for IBM

flag -> flags

> +@code{long double} format) as errors; although most of the implementation
> +shows errors smalls than the limit.

"implementation shows errors smalls" -> "implementations show errors 
smaller"

> +A more comprehensive analysis of @theglibc math function precision could
> +be found in 'Accuracy of Mathematical Functions in Single, Double, Double
> +Extended, and Quadruple Precision'; Brian Gladman, Vincenzo Innocente,
> +John Mather, and Paul Zimmermann at
> +@url{https://members.loria.fr/PZimmermann/papers/accuracy.pdf}

Note that this reference does not cover complex functions, or jn/yn, or 
any architecture variations (in particular IBM long double is out of 
scope).

(The known cases of very large errors are cpow, jn and yn for all formats, 
and j0/j1/y0/y1 except for binary32.  The previous table in the manual 
didn't deal with those cases of very large errors since they didn't go in 
the testsuite.)

> +A "libm-test-ulps" is required only to test for extra contraints in

contraints -> constraints

> +The keywords are float, double, ldouble, and float128.

I think it would be better for the keywords to be based on the format, not 
the type.  (In particular, if in future we have correctly rounded 
binary128 implementations, of rsqrt or cbrt or hypot, say, it would be 
desirable to have a single libm-test-ulps file describing those, rather 
than needing separate files for when those implementations are used for 
long double and when they are used for _Float128.  Though since those 
cases get the implementations via different sysdeps directories, our 
sysdeps system isn't really designed for this; the file would need to go 
somewhere more generic such as sysdeps/ieee754/.)

(Really the rounding mode shouldn't be treated as part of the function 
name either, but that might be a more complicated change.)

> +Also, muultiple "libm-test-ulps" can be added, "gen-libm-test.py" will

muultiple -> multiple

-- 
Joseph S. Myers
josmyers@redhat.com