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: "Carlos O'Donell" <carlos at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery 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: Wed, 24 Apr 2013 17:12:25 -0400
- Subject: Re: libm-test.inc: Computing ulps near FP_ZERO.
- References: <51606D8A dot 9080003 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1304191627070 dot 21258 at digraph dot polyomino dot org dot uk>
On 04/19/2013 12:46 PM, Joseph S. Myers wrote:
> 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.)
Agreed. I'm glad we have some consensus here.
> * 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.
Agreed. For cpow we have it already.
> * 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.)
Interesting point.
> * 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.
Also an interesting point. I had not thought to run the rounded input
values for the other formats as inputs to the other formats.
> * 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.
Agreed, that sounds very good.
> (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.)
Agreed, sounds good. The goal here is to have some way to regenerate them.
Cheers,
Carlos.