This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: libm-test.inc: Computing ulps near FP_ZERO.
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Andreas Jaeger <aj at suse dot com>, Thomas Schwinge <thomas at codesourcery dot com>, David Miller <davem at davemloft dot net>
- Date: Fri, 19 Apr 2013 16:46:00 +0000
- Subject: Re: libm-test.inc: Computing ulps near FP_ZERO.
- References: <51606D8A dot 9080003 at redhat dot com>
I'll answer several points from around this thread together:
* 1ulp for zero should be considered to be the least positive subnormal
number, the same as if the expected value is subnormal, or normal with the
least normal exponent. Making this so in the testsuite has been on the
wiki todo list for some time. (I knew that my recent fixes for casinh /
casin / cacosh / cacos would be needed for that to be possible, because of
tests that involve clog of something whose mathematical value lies on
|z|=1 but isn't exactly representable in floating point.)
* As I noted in
<http://sourceware.org/ml/libc-alpha/2013-01/msg01016.html>, LSB bugs
relating to "known" glibc issues need bugs filed in glibc Bugzilla. For
the case of cpow there's a bug, although not really about the specific LSB
case; for many more I think such glibc bugs are still needed.
* Making cpow accurate in general requires atan2/log computation to high
precision, maybe using AGM-based algorithms, as I noted in bug 14473.
(The atan2 computation probably *will* need to have special cases for when
the result is an exact multiple of pi/4, as in the case noted for LSB.)
* Testing input values such as M_PI_2l in the testsuite is problematic for
the reasons discussed. In general, testing any input that is not exactly
representable (such as 0.1L, for example) can be problematic in that it
means the exact expected result varies between floating-point formats. In
such cases, it's best to test all the rounded input values separately,
specified as hex floats. So rather than the present tests that use
M_PI_2l as input, there should be a series of tests with hex float values
as inputs - the value of pi/2 rounded to float should be tested for all
floating-point formats, the value rounded to double should be tested for
all formats except double, etc. (decimal is fine for expected *outputs*).
This way, the if the values of one floating-point type are a subset of
those of another type, so are the testcases for the respective types.
* Ideally, most of the tests for specific finite inputs should be
generated more automatically using MPFR/MPC rather than having people
cut-and-paste them into libm-test.inc. Again, this has been on the wiki
todo list for some time. Where the test input is exactly representable,
this would generate one test for each floating-point format, for each
rounding mode. Where not representable (e.g. 0.1 or pi/6), the value
would be rounded both up and down to each format, and the results tested
for each format in which the rounded value is representable (so the subset
property holds) - and MPFR/MPC would generate exact expected results for
each (format, rounding mode) pair. Such testing would mean substantially
more tests run than at present, but the libm tests are quick to run, even
on systems using software floating point, so I don't think that's a
problem. It would, I think, be appropriate for tests of each function (or
indeed each (function, rounding mode, error handling) combination) to be
run separately from the makefiles, rather than from the huge test
executables used at present - libm-test.inc is one of the largest files in
the source tree.
(The expected results generated by MPFR/MPC would need to be checked in,
to avoid depending on users having sufficiently recent versions including
development packages installed. Also, MPC is massively slower than glibc
at computing the functions for some of the test inputs, so generating the
expected results for some functions using MPC can take several minutes.
There would, I suppose, be makefile rules to regenerate all the
MPFR/MPC-generated values, or just to generate the values for newly added
tests.)
--
Joseph S. Myers
joseph@codesourcery.com