# [Maxima] Simplifying functions in Maxima code

Robert Dodier robert.dodier at gmail.com
Thu May 3 16:44:28 CDT 2007

```On 5/3/07, Stavros Macrakis <macrakis at alum.mit.edu> wrote:

> I've always preferred writing simplifiers in Lisp to using pattern matching
> in Maxima (sorry, RJF).  Though in the end you can probably get the same
> results, it's quite a different style of operating, with its advantages and
> disadvantages.  The big advantage of the pattern-matching style is that it
> is more modular in many ways; but I find it harder to work with -- mostly
> just a personal preference, but without a simpfuncall function, the logic to
> avoid infinite recursion can get annoying.

Well, I'm not opposed to simpfuncall/simpfunmake, since that
is something new. (Although I wonder if one or the other is enough.)

>  Yes, given simpfuncall, you can circumvent the matching part by simply
> doing something like this:
>
>               matchdeclare([any1,any2...], true)
>        simp:false\$
>       tellsimp( myfun( any1, any2...), myfun_simp( any1, any2, ...))\$
>       simp:true\$
>        myfun_simp(x,y,z):= ... else simpfuncall('myfun, ...)
>
> which should have the same black-box behavior as my simplifying code.

Yes, that is what I had in mind.

>  You mention that you found that simplifying is incompatible with tellsimp
> and built-in rules (I assume you mean things like commutative) -- please
> provide the failing test cases and I'll fix the bug if I can.

Well, simplifying appears to clobber any existing simplification
function (and it prints a warning about that). Simplification
functions generated by tellsimp and tellsimpafter chain themselves
to any existing simplification functions.

> > simplifying(foo, bar) is somewhat shorter than the equivalent
> > matchdeclare + tellsimp/tellsimpafter incantation, so simplifying
> > could be useful as a convenience function.
>
> Sure, that's an alternative implementation of simplifying(...), though it
> doesn't currently handle n-ary functions (which was why I wrote it,
> actually).

At present tellsimpafter (but not tellsimp) can handle the built-in
n-ary operators MPLUS and MTIMES. I have been thinking for
some time about extending tellsimpafter and maybe tellsimp to
handle other n-ary operators (user-defined or built-in) in the same
way that MPLUS and MTIMES are handled.
Maybe now is the time to go ahead and do that; I don't think
it would be very hard.

tellsimpafter's handling of n-ary operators is somewhat idiosyncratic;
we could consider reworking that, but I'm not much interested
in that, since it works well enough as it stands.

> So what would be the practical consequences of having simplifying be
> implemented in terms of tellsimp rather than Lisp code?

Well, (1) we can guarantee simplifications defined via simplify
act exactly the same as those defined via tellsimp/tellsimpafter;
(2) simplify plays nice with tellsimp/tellsimpafter and built-in rules;
(3) less complex new code to be written; (4) avoid inventing
another rule mechanism (there is already the letrule stuff which
is not compatible with tellsimp and friends).

FWIW
Robert
```