On 4/28/2011 8:18 AM, Robert Dodier wrote:
> On 4/27/11, Richard Fateman<fateman at eecs.berkeley.edu> wrote:
>
>> for a start, a rule tellsimp(a.b, ....) cannot be used to match any
>> dot product of 3 or more items.
> Yes, but a . b. c is actually parsed as a . (b . c) and then
> simplified to a . b . c
> (i.e. one operator with three arguments) and the tellsimp rule is applied
> before flattening the expression.
It is a really bad idea to assume that the input to a function is not
simplified for tellsimp to work.
> However, it would be pretty easy to construct cases for which the tellsimp
> rule isn't applied as soon as the input is parsed. Then the rule could fail.
> e.g. input a . b . c then reevaluate it with a, b, and c bound to something.
Yes.
>> turning simplification off around rule definitions is generally a bad idea,
> Not so.
It makes sense only if you want to place rules on things like 1/0 or
0^0. That is, you want to over-ride some built-in simplification.
Otherwise it is a bad idea because (in general) the "left hand sides
unsimplified" of the rules will not appear in expressions. Only some
simplified version of them will appear, and either (a) they may not
match or (b) it will take extra effort to make them match. To blindly
copy this "simp:off / simp:on" as idiomatic usage of tellsimp is a bad idea.
It may seem, superficially, that in defining a whole bunch of tellsimps
that you want to define them in isolation from each other (that is, with
simp turned off), but in reality the only way they can operate is with
all of them interacting. You might as well face that when you define
the rules so they operate together.
A better way, for many tellsimps, may be to define rules via defrule,
and then sequence through them as appropriate. (perhaps via ONE tellsimp
or tellsimpafter). That way, in debugging, you can watch what they are
doing more easily.
RJF