On 5/3/07, Robert Dodier <robert.dodier at gmail.com> wrote:
>
> Well, I'm not opposed to simpfuncall/simpfunmake, since that
> is something new. (Although I wonder if one or the other is enough.)
Yes, of course the functionality is redundant, just a matter of convenience
and taste.
> 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).
That is intentional, and to my mind makes sense in this scenario. I'd like
simplifying(...) to act like :=, namely to override any preexisting
definitions. This can certainly be changed if necessary. On the other hand,
subsequent tellsimp's should work fine.
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.
Well, that would certainly make 'simplifying' less compelling. But I am not
sure what you mean by "the same way as mplus and mtimes"; the handling of
those operators depends on their being associative and commutative. Other
n-ary functions may not have those properties.
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;
See above; simplifying actually does "play nice" -- it overrides any rules
at the time it is defined, but any rules added afterwards work fine.
(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).
Yes, you have a point. Though if we treat simplifying(f,simp_f) as
syntactic sugar as above, as far as the user is concerned, it might as well
be a new mechanism.
-s