Re: test, string and special matrix funcs

[Paul Kienzle]

>From address@hidden Wed May  3 21:57:51 2000
>  Hello,
>
>  I would like to do, in the next weeks, the following :
>
>  build 2.1.30 so that it incorporates Paul Kienzle's test functions :
>
>testfun/pretty.cc        goes into src/DLD-FUNCTIONS
>testfun/pretty           goes into ??
>
>testfun/demo.m           goes into scripts/general or miscellaneous
>testfun/example.m        goes into scripts/general or miscellaneous
>testfun/test.m           goes into scripts/general or miscellaneous
>
>testfun/octave-mod.el    goes into emacs
>
>  And then send a patch.

Since the test functions will have such a wide ranging impact on the
system (ideally touching every script file and then some) the interface
should be rock solid stable and unchanging.  That means that many people
should be trying them out on various functions so that any weaknesses in
the design are clear at the outset.  Going through some of the expect
scripts is a good place to start.  Bugs in the code is not the issue
here --- they are local, but bugs in the design are not.

Me, I'm mostly happy with things.  I'm vacillating on whether there
should be a "usage" keyword in addition to "error".  Just because I
can't detect the difference now doesn't mean that we won't be able
to in the future.  Perhaps error should be able to search the text
of the error message to verify that it contains one or two key
words (including the whole message seems wrong).

I'm a little worried about dumping all those idle test scripts into my
running octave process.  Octave does not strip comments when it loads
the function.  Perhaps we should leave tests in .test files where they
only takes up disk space?  Or maybe octave should leave off comments
which start '%!'? (Okay, so the total size of all scripts combined in
2.1.28 only takes up 1.4 Mb, and the whole of the test tree a mere 95k,
so not such an issue).

Assert could perhaps use negative tolerance to indicate relative
error and a positive tolerance to indicate absolute error rather than
having the extra parameter 'rel'.  Which is less obscure?

It would be nice to have some sort of control flow.  For the string tests,
I found myself copying all the tests verbatim for the various functions,
only changing the name of the function being tested the expected outcome
was already in a shared variable.  The name of the function should have
been in a shared variable too, but I wasn't that clever at the time.
Even only sharing variables, I had some difficulty determining which
line of test script caused the error, since the tests were generic and
I had the "passed tests" turned off.  Thinking about it now, it would
be easy enough to dump the current shared variables on test failure,
and that should fix that problem.  The control flow problem, though,
is most easily tackled by putting multiple asserts in the same test
block and using octave's control flow to direct it.  That does mean that
remaining asserts in that test block will not get tested if one of them
causes an error, but that seems a small price to pay for control flow.
Note: an even more striking example of the need for control flow came
about when writing the test script for my function interp1.  Here, each
type of interpolation had to be tested fully separately, but all shared
exactly the same input and output.

So you see why I want tests scripts hammered on a bit before including
them?

>
>  Install the new string and special matrix functions, tests them by
>comparing their output to the old function's output, and send a
>patch. 

They are already submitted as patches, but some confirmation from an
independent party that they work the same as the old ones should
certainly make it easier for jwe to accept the patch.  BTW, I was not
comma conscious at the time I updated the matrix functions and I'm
certain to have missed a couple.  I'll let you run your tests first
to see if there are any other problems before resubmitting.

Note, this is how to check for 'missing' commas:

        whitespace_in_literal_matrix="ignore"

Do it before you load in the function, though!

>
>  Do the patches have any chance of getting in? I can also just patch
>my 2.1.19 installation and spare myself some work. 
>
>  What if I sent (again) a patch for 'exist'? 

I would like to see exist('name','var') added as well, though I haven't
tested this particular patch.  For compatibility if for no other reason.
And I have to admit, having separate functions for doing the same
thing is starting to get on my nerves.  'tolower' vs. 'lower' for example.
One of them is "cruft", but I'm not sure which.

> A replacement for
>'cross'? Eventually a DLD for 'kron' (if it turns out faster than
>Paul's new function)?

How could it not be?

>
>  Etienne
>

Paul Kienzle
address@hidden




-----------------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.che.wisc.edu/octave/octave.html
How to fund new projects:  http://www.che.wisc.edu/octave/funding.html
Subscription information:  http://www.che.wisc.edu/octave/archive.html
-----------------------------------------------------------------------