Here is a patch that replaces some of the numbers in the tests with symbolic values so that it's easier to see what the tests are trying to do.
I'm sure not all the well-known values have been converted, but this is a start.
Ray
Raymond Toy toy@rtp.ericsson.se writes:
Here is a patch that replaces some of the numbers in the tests with symbolic values so that it's easier to see what the tests are trying to do.
I've got no objections to this (and indeed would encourage people, while we're in the exploration and development phase of this project, to make speculative commits without worrying too much. I will scream if you break stuff, but hey -- don't let that stop you ;-).
In the long term, I enviseage that this mechanism would be replaced by two things: firstly, that the tests would be preceded by an automatically generated comment (or would contain a docstring) describing the test: maybe something like "(atanh 0.5d0) => f00d0" as a quick summary, with obvious Inf and NaN notation; secondly that the tests be automatically annotated with such notes (in the Dietz-style-RT sense) as :argument-is-nan, :result-is-inf, :rounding-mode-nonnearest, and so on, so that implementations which aren't fully IEEE compliant can ignore those tests with notes corresponding to unimplemented (or unimplementable) features.
(one other thing to bear in mind: my suspicion is that the act of wanting to test ieee features will lead to a pseudo-compatibility library for ieee functionality, living in ieee754-fooimpl.lisp; with luck, we'll be able to find a nonhorrible API that can be written up and submitted to whatever standardization body still exists by the time we get there :-)
Cheers,
Christophe
"Christophe" == Christophe Rhodes csr21@cam.ac.uk writes:
Christophe> In the long term, I enviseage that this mechanism would be replaced by Christophe> two things: firstly, that the tests would be preceded by an Christophe> automatically generated comment (or would contain a docstring) Christophe> describing the test: maybe something like "(atanh 0.5d0) => f00d0" as Christophe> a quick summary, with obvious Inf and NaN notation; secondly that the
I agree. This is important. I think the constants should still remain since it still makes it easier to read the test.
Christophe> (one other thing to bear in mind: my suspicion is that the act of Christophe> wanting to test ieee features will lead to a pseudo-compatibility Christophe> library for ieee functionality, living in ieee754-fooimpl.lisp; with Christophe> luck, we'll be able to find a nonhorrible API that can be written up
I'm more willing to blame the libm vendor and/or chip for problems. I'm not really keen on implementing a compliant cosh implementation, for example.
Ray
Raymond Toy toy@rtp.ericsson.se writes:
(one other thing to bear in mind: my suspicion is that the act of wanting to test ieee features will lead to a pseudo-compatibility library for ieee functionality, living in ieee754-fooimpl.lisp; with luck, we'll be able to find a nonhorrible API that can be written up
I'm more willing to blame the libm vendor and/or chip for problems. I'm not really keen on implementing a compliant cosh implementation, for example.
Ah, sorry, that's not what I meant. I meant tools such as for inspecting the accrued exceptions, setting the rounding mode, examining the operands of a trapping instruction, getting the sign/mantissa/exponent of a float, examining the nonsignificant bits of a NaN, unordered comparison operations, and so on. Operations that are specified in ieee754 as "would be nice".
Cheers,
Christophe
"Christophe" == Christophe Rhodes csr21@cam.ac.uk writes:
Christophe> Raymond Toy toy@rtp.ericsson.se writes: >> > (one other thing to bear in mind: my suspicion is that the act of >> > wanting to test ieee features will lead to a pseudo-compatibility >> > library for ieee functionality, living in ieee754-fooimpl.lisp; with >> > luck, we'll be able to find a nonhorrible API that can be written up >> >> I'm more willing to blame the libm vendor and/or chip for problems. >> I'm not really keen on implementing a compliant cosh implementation, >> for example.
Christophe> Ah, sorry, that's not what I meant. I meant tools such as for Christophe> inspecting the accrued exceptions, setting the rounding mode, Christophe> examining the operands of a trapping instruction, getting the Christophe> sign/mantissa/exponent of a float, examining the nonsignificant bits Christophe> of a NaN, unordered comparison operations, and so on. Operations that Christophe> are specified in ieee754 as "would be nice".
Oh, that's much better. This is more interesting and more useful.
I guess the first order of business is to implement nextafter, which I don't think any Lisp has implemented.
Ray
ieeefp-tests-devel@common-lisp.net
-
Christophe Rhodes -
Raymond Toy