... and non-associative, so a rule like a+c => q or c+a => q won't match
any part of a + c + 1, let alone a + b + c (commutative and associative).
-s
On Wed, May 22, 2013 at 12:50 PM, Robert Dodier <robert.dodier at gmail.com>wrote:
> On 2013-05-22, Barton Willis <willisb at unk.edu> wrote:
>
> > (%i1) tellsimp(b+1,z);
> > tellsimp: warning: putting rules on '+' or '*' is inefficient, and may
> not work.
> > (%o1) [+rule1,simplus]
>
> > Not OK -- b+1 isn't automatically simplified to z:
> >
> > (%i4) b+1;
> > (%o4) b+1
> >
> > (%i5) expand(%,0,0);
> > (%o5) z
>
> The code generated by tellsimp for "+" and "*" doesn't make use of PART+
> and PART*, respectively, which treat them as commutative operators, and
> tellsimp rules are applied before built-in rules, so terms have not yet
> been reordered. So the rule generated here is sensitive to the order in
> which you enter the terms -- try 1 + b instead of b + 1.
>
> I suppose it is plausible that "+" and "*" cannot be considered
> commutative until the built-in rules have been applied. Maybe, maybe not.
>
> From time to time I think I should rework tellsimp to generate the same
> stuff for "+" and "*" as tellsimpafter (which applies PART+ and PART*).
> An easier fix in the short term is to clarify the warning message --
> "may not work" --> "operator is treated as noncommutative".
>
> best
>
> Robert Dodier
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>