Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: list of operations for test suite. suggested format

Title: IEEE Std 754™-2008 (Revision of IEEE Std 754-1985), IEEE Standard for Floating-Point Arithmetic
On 4/28/13 8:19 PM, Dmitry Nadezhin wrote:
Richard,

1) I would like to use in test suite symbolic names like "add" instead of numbers.
I would personally  prefer this too.  I was trying to make it perfectly unambiguous and not have
to worry about character sets, capitalization, Add vs ADD vs unicode vs ASCII.
2) Is it necessary to put name on every line ? There may be a header line
with operation name before a few lines with operation instances.
  I think each line should stand alone without reference to any other line, so that the
line can be run through a program all by itself.
3) The number can of inputs in operation instance is fixed for most operations.
Yes
  It is variable for such operations like "min", "max".
  There are also overloaded reverse operations invRev(c) and invRev(c,x).
  Nevertheless, reader can count number of inputs in a line for such operations.
I am trying to make the access entirely uniform and not make the reader program
any more complicated than necessary.
  It is not necessary to write the counter explicitly
For the same reason as above, I think each line should have a sequence number.
There might be gaps in the sequence, but I think it is good for each line to be
referred to by a single identifier so you can say "my program gets a different
result for line  xxxxx.  Is my program wrong or is the test suite wrong?"

4) The outputs may be optional for some tools.
   For example Reference Checker reads input, computes tightest interval internally and checks
   that it implementation under test returns result that contains the tightest.
I don't have "reference checker" in my list.  But if it computes something like
"Yes this result is checked"  then I suppose it could be added to the test suite.
If a program has no output then it computes nothing and can be discarded :)

   I suggest to separate inputs and outputs (if present) by some mark, for example "->".
why?   A program to read and format the test suite,  or to parse some other input and produce the
test suite format, could be written .  I wanted to make the format so simple that any programming
language could easily read it, and not have to check to see if the next field is a number or a mark.


5) I suggest to use "hexadecimal-significand" form as described in section 13.4 of Draft 7.1
   instead of tripples.
I disagree.  Why should each person have to write a parser for such elaborate stuff. Furthermore, it
doesn't even cover everything the triples cover, because it deals only with finite numbers not
infinities etc etc.   Furthermore, the representations are subject to rounding to get to the actual
numbers.   So, unless I am misunderstanding something here, it looks unsuitable.

For those who do not have 754-2008 at their fingertips  (I had to search for it...)
Here's just the first part of the section:

  1. 5.12.3 External hexadecimal-significand character sequences representing finite numbers 5.12.3.0

    Language standards should provide conversions between all supported binary formats and external hexadecimal-significand character sequences. External hexadecimal-significand character sequences for finite numbers shall be described by the following grammar, which defines a hexSequence:

sign
digit
hexDigit hexExpIndicator hexIndicator hexSignificand decExponent hexSequence

[+ −]
[0123456789]
[0123456789abcdefABCDEF]
[Pp]
"0" [Xx]
( {hexDigit} * "." {hexDigit}+ | {hexDigit}+ "." | {hexDigit}+ ) {hexExpIndicator} {sign}? {digit}+
{sign}? {hexIndicator} {hexSignificand} {decExponent}


..........
6) Is test sequence number necessary ?
   Shouldn't it be optional
No, but if you wish to provide a test, I will be happy to provide a test sequence number for it!

7) Are comments allowed
I'm agreeable to anything that is convenient.
What would you like?
  For Lisp, the convention is that any line beginning with semicolon  ";" is a comment.
If you want to use some convention for comments at the end of a line, that's OK too.
If you wish to use //  or ....  # that's OK with me.

alternatively, since each line has a sequence number, a separate file with sequence numbers and comments
may be useful;  this may keep the test file relatively compact.

........

Frankly, I don't know what you mean by [1,2].
Is the input widened? is the output?   how do you express oo or -oo?

I have not put notation in for decorations.  I would prefer that stuff not be alphabetic.
I suppose that each interval could be  (triple)(triple) DECORATION
where DECORATION is 0,1,2,3,4  
Though illegal and empty can be detected by special triples, I think.
com, dac, def  may be all that is necessary.
RJF

So I would like to see a testsuite file like this:
====
* inv 
[1,2]             # Without output
[1,2] -> [-2,-1]  # With output
50001: [0x1.0p0,0x1.0p1]_com -> [-0x1.0000000000000p1,-0x1.0000000000000p0]_com
* min
[1,3] [2,4] -> [1,3]
[1,3] [2,4] [0,6] -> [0,3]
[1,3] [2,4] [0,6] # Without output
====

  -Dima