This page is part of the web mail archives of SRFI 64 from before July 7th, 2015. The new archives for SRFI 64 contain all messages, not just those from before July 7th, 2015.
At Sat, 19 Mar 2005 14:55:23 -0800, Per Bothner wrote: > > Any preferences for or against these changes? > > (1) Move optional test-name to the end of the argument list? Against. > (2) Move the "expected value" argument *before* the "expression to > evaluate" argument. E.g. instead of: > (test-eqv test-expr expected) > we'd use: > (test-eqv expected test-expr) [...] > Aubrey argued for this change. It turns out JUnit also has the > "expected" value as the first operand. Gauche also puts the expected value first. > (3) We need some routines for testing inexact numbers. > I suggested earlier: > > (test-approximate [test-name] test-expression expected [error]) > where is a relative error which defaults to 0.001. Equivalent to: > (test-assert (and (>= result (- expected (* expected error)) > (>= result (+ expected (* expected error))))) [I think you meant <= for the second >=.] How can both the name and error be optional in the above syntax? Perhaps it would be easier to use a global parameter (or possibly associated per group or test suite) for the relative error. A good default is hard to choose. SRFI-56 uses 0.00001 for its inexact tests and several Schemes manage to pass, but it isn't compounding a large number of inexact operations as you'd find in some algorithms. -- Alex