Re: libm-test.inc: Computing ulps near FP_ZERO.

["Carlos O'Donell" <carlos at redhat dot com>]

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.