known maximal errors

known maximal errors

[Paul Zimmermann]

       Hi,

[1] gives a maximal known error of 0 ulp for hypotf on x86_64, but the
following gives an error of 1 ulp:

Checking hypot with glibc-2.37
hypot 0 -1 -0x1.003222p-20,-0x1.6a2d58p-32 [0.501] 0.500001 0.500000001392678
libm gives 0x1.003224p-20
mpfr gives 0x1.003222p-20

Same for binary64 tan:

tan 0 -1 -0x1.317cd745dd37cp+9 [1] [0.619] 0.618367 0.6183663571802361
libm gives -0x1.efcf403abf99ep+3
mpfr gives -0x1.efcf403abf99fp+3

and for atan2:

atan2 0 -1 0x1.ed6060626eecfp-429,0x1.f42ebb62994dcp-426 [0.524] 0.523171 0.5231707007273592
libm gives 0x1.f67f36f292b58p-4
mpfr gives 0x1.f67f36f292b59p-4

For binary64 sin a maximal known error of 2 ulps is given but I can only
find an error of 0.516 ulps, thus rounding to 1.
Do you have an example with 2 ulps on x86_64 ?

Best regards,
Paul

[1] https://www.gnu.org/software/libc/manual/html_node/Errors-in-Math-Functions.html

Re: known maximal errors

[Joseph Myers]

On Thu, 9 Feb 2023, Paul Zimmermann via Libc-alpha wrote:

>        Hi,
> 
> [1] gives a maximal known error of 0 ulp for hypotf on x86_64, but the
> following gives an error of 1 ulp:

This is generated from libm-test-ulps files.  You can add inputs resulting 
in larger errors to auto-libm-test-in and regenerate the relevant 
auto-libm-test-out-* file (and then architecture maintainers should update 
their libm-test-ulps files as appropriate).  If an input results in a 
larger error than the known maximum, but not large enough to be considered 
a bug and thus result in test failures whatever is put in libm-test-ulps, 
then it should be appropriate to add to auto-libm-test-in.

> For binary64 sin a maximal known error of 2 ulps is given but I can only
> find an error of 0.516 ulps, thus rounding to 1.
> Do you have an example with 2 ulps on x86_64 ?

libm-test-ulps files aren't often regenerated from scratch (note that they 
reflect maximal errors for the test inputs across a range of 
configurations, that may vary in e.g. when the compiler chose to contract 
operations, or whether an optimized implementation for a particular 
processor was used, so running the testsuite in a single configuration may 
not suffice to produce libm-test-ulps that will then result in it passing 
for all configurations).  So they may well contain entries that were 
correct for a previous version of the code but exceed the maximum error 
that can occur with the current code.

-- 
Joseph S. Myers
joseph@codesourcery.com