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

[Stavros M. <mac...@al...>]

factor(<number>) is a *hack* intended to do the "obvious" thing for the
beginning interactive user. cf. https://en.wikipedia.org/wiki/DWIM
Like other DWIM features in Maxima, notably *ev*, it works fine most of the
time, especially in interactive use... at a cost...

It should certainly not be used programmatically -- that is what *ifactors* is
for.

On Sun, Feb 28, 2021 at 9:52 AM Gunter Königsmann <gu...@pe...>
wrote:

> The fact that factor() can do three things (factor numbers, factor
> expressions and try harder to do so within scanmap) often causes confusion
> between users. I guess it also makes coding more difficult at times...
>
> Am 28. Februar 2021 02:36:48 MEZ schrieb Robert Dodier <
> 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
>> ------------------------------
>> Maxima-discuss mailing list
>> Max...@li...
>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>
>>
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
>