Re: P-1788: Prospects for the new year
Let me introduce myself.
I am one of developers of Java interval library JInterval
http://kenai.com/projects/jinterval
Recently we decided to rewrite it to Scala and try to make it conformant to
the coming interval standard P1788.
I read in this mail-list the New Year message "P-1788: Prospects for the new year"
I would like to share with you my thoughts about architecture of a reference
implementation and a test suite
Standard can specifiy results of some operations in a unique way,
though results of other operations may be a little sloppy.
Let us take for example the midpoint operation "double mid(DoubleInterval x)".
If for some "x" the exact midpoint is not a double number,
the standard should allow (I hope) this operation to return any
of two double numbers that surround the exact midpoint.
The specification of the "mid" operation by mapping from input to output may be restrictive.
IMHO, the specification of "mid" operation should look like a predicate on input and output:
"boolean midShall(DoubleInterval x, double result)"
or
"boolean midShould(DoubleInterval x, double result)".
Ideally, such predicate should be defined in some proof checker language (like Coq).
However, I guess that this will happen only after adoption of the standard.
More quicker way is to define these predicates in a programming language.
The program component with such predicates can be called "checker".
The checker is a normative program component,
it expresses wordings of the standard in a computer-executable way.
A test suite for some operation is a program component that generates a stream of inputs for this operation.
It may be a plain reader of file with test inputs.
It may be a generator of random inputs.
It may be an algorithm that enumerates corner cases.
The test loop of a any implementation of P1788 that defines the "mid"
operation as well as others will look like
====
for (DoubleInterval x: midTestSuite.inputs()) {
double result = implementation.mid(x);
if (!checker.midShall(x, result)) println("failure");
}
====
The reference implementation must pass the above test loop, of course.
But I don't consider reference implementation as a normative program component.
Rather it is a proof of concept. It shows that the operation of the standard
can be implemented with a reasonable performance.
Perhaps a few reference implementation may exist.
One returns the tightest results, but it is slow.
The other is faster, but its results are not always the tightest.
These reference implementations can be written in different
programming languages.
So the framework in my opinion consists of:
* normative checker;
* testSuits;
* variants of reference implementations (perhaps in different programming languages);
* launcher.
The launcher is a component that
1) dynamically links ".jar"/".dll"/".so" file with particular
reference implementation,
2) loads testSuits
3) runs the testing loop.
What do you think about such framework ?
Isn't it too complicated ?