On 5/3/07, Robert Dodier <robert.dodier at gmail.com> wrote:
>
> I guess I don't see a need to build another mechanism to introduce
> user-defined simplifications
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.
matchdeclare + tellsimp/tellsimpafter already can introduce a function which
> is called every time a
> specified operator is simplified.
>
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. I
don't think we can handle n-ary functions in tellsimp, but we should be able
to extend it.
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.
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).
So what would be the practical consequences of having simplifying be
implemented in terms of tellsimp rather than Lisp code?
-s