[PATCH] add inputs to auto-libm-test-in yielding larger errors
Paul Zimmermann
Paul.Zimmermann@inria.fr
Tue Dec 1 10:29:10 GMT 2020
Dear Joseph,
> Date: Mon, 30 Nov 2020 22:21:24 +0000
> From: Joseph Myers <joseph@codesourcery.com>
>
> On Mon, 30 Nov 2020, Paul Zimmermann wrote:
>
> > Dear Joseph,
> >
> > submitted as https://sourceware.org/bugzilla/show_bug.cgi?id=26982, and a
> > similar one for tgamma (https://sourceware.org/bugzilla/show_bug.cgi?id=26983).
>
> Thanks. It would be interesting to know if similar cases can be found for
> other floating-point formats (inputs with large errors for different
> formats could go in the same bugs rather than needing a separate bug for
> each format) as that might affect how many implementations need to get
> similar fixes. You've done exhaustive searches for float. But have you
> looked for such large errors for these functions for ldbl-96 (x86 extended
> precision) or ldbl-128 (binary128), for example? (Or for ldbl-128ibm,
> with the larger threshold of permitted errors there and the definition of
> ulps that treats it like a format with exactly 106 bits of precision.)
so far I plan to look for large errors for binary32, binary64 and binary128,
for the 6 following libraries: glibc, Intel Math Library, AMD Libm, Redhat
newlib, OpenLibm and Musl (as far as I know only glibc and the Intel Math
Library do support binary128), on x86_64. I also plan to deal with bivariate
functions (pow, atan2, hypot). I will publish the largest errors found (with
corresponding inputs), as I already did for binary32.
For other formats, it should be easy to adapt my search program. If someone
is interested to help with ldbl-96 or ldbl-128ibm, please tell me and I will
send you my program.
Paul
More information about the Libc-alpha
mailing list