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] |

*From*: "Joseph S. Myers" <joseph at codesourcery dot com>*To*: OndÅej BÃlka <neleai at seznam dot cz>*Cc*: <libc-alpha at sourceware dot org>*Date*: Sun, 5 May 2013 14:06:29 +0000*Subject*: Re: Improving libm-test.inc structure and maintenance*References*: <Pine dot LNX dot 4 dot 64 dot 1305022244550 dot 12072 at digraph dot polyomino dot org dot uk> <20130505130414 dot GA18328 at domone dot kolej dot mff dot cuni dot cz>

On Sun, 5 May 2013, Ondrej Bilka wrote: > Why do auto-libm-test-out have to be checked in? If outputs be computed > automaticaly we can save them in test directory. I could write utility > that caches mpc results on disk and returns them. Generating expected results would dominate the time required for a complete testsuite run if it wasn't checked in; build/test directories are generally expected to be transient. Also, I don't want to assume the user testing glibc has an MPC version recent enough to contain mpc_log10, but do want to use mpc_log10 when generating the expected results rather than hacking around its absence. Nor do I want MPFR or MPC bugs to cause different people to get different glibc test results because their expected results were computed differently. > One possibility would be use dryrun format which also could allow > automate bug report of inaccurate results. I could combine this with > program that tries random values and looks for inaccuracies. I think testing random values (cf. also Jakub's code to do such testing for fma), probably with appropriate biases to include reasonable proportions of large inputs, small inputs, etc. rather than being uniform across the exponent range, is best as a separate project that could test more libm implementations than just glibc. See the last point under "libm testsuite" at <http://sourceware.org/glibc/wiki/Development_Todo/Master>. Humans then need to review results to identify if bugs found are genuinely new before reporting them. I should perhaps add what I think the goal is for how libm functions behave, and that such random tests should test: Each function with a floating-point result (real or complex) should behave as if it computes an infinite-precision result that is within a few ulp (in both real and complex parts, for functions with complex results) of the mathematically correct value (interpreted together with ISO C or POSIX semantics for the function in question) of the function at the exact value passed as the input. Exceptions should be raised, and errno set, appropriately for this value (provided that there is no requirement to set errno for complex functions) and in accordance with ISO C / POSIX semantics, and it should then be rounded according to the current rounding direction to the result that is returned to the user. Functions should behave as if the infinite-precision result computed is zero, infinity or NaN if and only if that is the mathematically correct infinite-precision result. They should behave as if the infinite-precision result computed always has the same sign as the mathematically correct result. If the mathematical result has magnitude well below half the least subnormal magnitude, the returned value should be either zero or the least subnormal (in each case, with the correct sign), according to the current rounding direction and with the underflow exception raised. If the mathematical result is more than a few ulp above the overflow threshold for the current rounding direction, similarly the value returned should be the appropriate overflow value for the current rounding direction, with the overflow exception raised. Where the mathematical result underflows and is not exactly representable as a floating-point value, the underflow exception should be raised (so there may be spurious underflow exceptions in cases where the underflowing result is exact, but not missing underflow exceptions in cases where it is inexact). All the above applies to both real and complex parts, for complex functions. In addition to the above, for fully-specified functions such as fma, sqrt and rint, the result and corresponding exceptions should be exactly according to the fully-specified semantics of the function; there should be no spurious or missing exceptions, including "inexact" exceptions. This includes detection of tininess for underflow exceptions in the same way as for other operations with binary floating-point results on the architecture in question, in accordance with the requirements of IEEE 754-2008. (There are a few existing fma tests using UNDERFLOW_EXCEPTION_BEFORE_ROUNDING to verify such architecture-specific requirements for fma.) -- Joseph S. Myers joseph@codesourcery.com

**Follow-Ups**:**Re: Improving libm-test.inc structure and maintenance***From:*OndÅej BÃlka

**References**:**Improving libm-test.inc structure and maintenance***From:*Joseph S. Myers

**Re: Improving libm-test.inc structure and maintenance***From:*OndÅej BÃlka

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |