Re: New version of John Hayes' tester

Anton Ertl wrote:
Krishna Myneni <krishnamyneni@xxxxxxxxxxxxx> writes:
Anton Ertl wrote:
However, it does not fix the empty-stack-only shortcoming, and the
only potential advantage it has over my extension is that the
approximate comparison can be more finely tuned.

Perhaps this tuning can be folded into your version (in particular, the use of
the ?EXACT flag to force exact fp comparisons).

The matching is exact by default (FSENSITIVITY is set to 0E), and you
can make it exact with

decimal 0e fsensitivity f!

Or do you mean that you want to have words EXACT?, SET-EXACT, SET-NEAR
as present in ftester.fsq?


Yes. These words are convenient so that one does not have to remember how the
sensitivity parameter has to be specified.

Concerning the fine-tuning, I meant the REL-NEAR and ABS-NEAR stuff;
with FSENSITIVITY you can do either relative (negative FSENSITIVITY)
or absolute (positive FSENSITIVITY) approximate comparison, but not
both at once. Do you use that?


When a nearness comparison is made, ftester does both absolute nearness
("FABS=") and relative nearness ("FREL=") comparsions in the word "FNEARLY=".
There are two different parameters to specify the absolute and relative
tolerances (sensitivities).

Offhand it seems that one test or the other would be sufficient; however, one
may want to do both tests if the results are being compared against reference
values on a system with unknown fp precision.

Perhaps David has another justification for doing both tests.


Hmm, I could add replacement words for } like FIFI}, which would
specify that the results are of the form ( r x r x ), and do
approximate comparisons for the rs; that would work for both
separate-stack and mixed-stack systems. The test above would then
look like:

decimal { s" 1.23" >float -> 1.23e true fi}
...
Thanks for offering, but I believe it is neither worth the time, nor desirable,
to add words like "FIFI}" to your module. I think integrated stack Forths will
have to work around this issue in a different way.

It's an interesting programming exercise, so I am tempted to implement
them anyway. You can then use it or work around the issue in a
different way at your choice. Why do you feel that it is not
desirable?

- anton

The reason I thought it undesirable was that you would have to implement
different words for different permutations and combinations of types. Wouldn't
that be a rather large set of words?

Krishna
.