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