On 2013-08-04, Wilhelm Haager <wilhelm.haager at htlstp.ac.at> wrote:
> (%i1) matchdeclare([aa,bb],lambda([u],symbolp(u) or numberp(u)));
> (%o1) done
> (%i2) defmatch(addp,aa+bb);
> (%o2) addp
> (%i3) addp(x+1);
> (%o3) [bb=x+1,aa=0]
>
> Why is bb so greedy and receives x+1?
> That is neither a symbol, nor a number.
> I would expect to get aa=1 and bb=x (or vice versa).
tellsimpafter, defmatch, and defrule (but not tellsimp -- I suppose
that's a bona fide bug) treat "+" and "*" as n-ary, commutative
operators. (But operators declared nary and commutative are not so
treated -- I've been meaning to add that functionality for some years.)
Each pattern variable is assigned a "+" expression capturing all the
terms which pass its match predicate. Since the predicates are the
same, one variable or the other (depends on ordering) captures all the
terms and the other gets none, except an implicit 0 term.
To make the outcome more comprehensible, my advice is to make the
match predicates mutually exclusive. Then each variables gets
exactly one kind of term.
> matchdeclare([aa,bb],lambda([u],symbolp(u)))
> and addp(x+y)
> results always in "false", even when both summands
> are symbols!
In this case, aa captures all the arguments and there are none left for
bb (not even the implicit 0), so the match fails.
Not a bug -- intentional behavior, and even documented (under
tellsimpafter, I believe). But I admit that it is pretty mysterious at
first.
best
Robert Dodier