On 5/7/07, Stavros Macrakis <macrakis at alum.mit.edu> wrote:Re my example:
matchdeclare([a1,a2],atom)$
> tellsimpafter(qqq(a1+a2,a1),rrr(a1,a2))$
> qqq(x+y,x) => qqq(y + x, x) no match
>
On the other hand....
matchdeclare([e1,e2],true);
tellsimpafter(hhh(e1,e1+e2),iii(e1,e2))$
hhh(x,x+y) => iii(x,y) works fine
This is because the pattern-matcher works strictly left-to-right, doing no
backtracking. In the first case, it would potentially have to try various
ways of partitioning the sum; in the second case, it doesn't need to; once
it's matched x to a1, the second part is clear. So you also get:
hhh( sin(x)/3-y , 0 ) => iii( sin(x)/3-y , y-sin(x)/3 )
In the case of laplace, you could define another version where the variable
comes before the expression, then all would be hunky-dory. You'd then do
something like
laplace(a,b,c) => xlaplace(b,c,a)
xlaplace(var,signum(var-const), param) => exp(-const*param)/param)
xlaplace(b,c,a) => laplace(a,b,c) (in case the xlaplace rule didn't get
triggered)
making sure that the third rewrite happened last and that it didn't get you
into an infinite loop -- perhaps with simpfuncall.
Once I start having to think like this, I find it a lot easier to think in
terms of old-fashioned imperative programming rather than pattern-matching.
I'm sure we could invent a better pattern-matching system, but until
then....
-s