[Maxima-discuss] verifying simplification in tests, was: sub expression with missing simp flags.

[Robert D. <rob...@gm...>]

On Sat, Feb 27, 2021 at 2:43 PM Stavros Macrakis <mac...@al...> wrote:
>
> The test suite should probably check that all outputs are:
>
> Fully flagged with simp flags.
> Unchanged when resimplified with expand(expr,0,0).

Okay -- I guess these are things that can be implemented in the code
which runs the tests. I forget what the function is called, but it's
in src/mload.lisp somewhere.

> Exception: factor(24) can best be tested with string(factor(24)), since args(factor(24)) tests correct with both [2^2,3] and [4,3] -- admittedly, factor(<number>) is a hack.

Yeah, that's pretty terrible. I wouldn't be too sad if
factor(<number>) went away. There is of course ifactors which has a
more useful output.

> Exactly as given -- the expected results should not be simplified before comparing, because that misses bugs in simplification. For example, the test a+x accepts both a+x and x+a as correct, even though only x+a is correctly ordered. For some new simplifications I'm working on, I have had to use the string() trick to test them.

There is some stuff about simplifying MQUOTIENT which has caused
heartburn at times -- I think I might have sometimes done something
like

<some input expression>;
''(expected output);

to ensure the expected output gets the same simplified form as the
actual output.

> We also need some tests for output form. This is easy for the 1d form using string, harder for 2d form.

It's not really too much trouble for 2d output -- what I have done
many times is to say

(S: make_string_output_stream (),
 with_stdout (S, print (my_test_function (x))),
 get_output_stream_string (S));
"a
-
b";

or whatever the expected string output is. I guess that's a bit of a
hassle, but it's not too bad.

best,

Robert Dodier