This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]