Hmm, actually, I'm wrong about "no verbs at all" in expressions. Something
like (if a>b then diff(x,y)) includes a verb when a>b is unknown, and the
simplifier is recursively applied to the verb form, as the following shows:
tellsimp(diff(x,y),foo)
if a>b then diff(x,y) => if a>b then foo
This is different from the lambda case:
lambda([],diff(x,y)) => unchanged
It still seems that the noun case is the natural interpretation in tellsimp.
-s
On Sun, Nov 25, 2012 at 5:25 PM, Stavros Macrakis <macrakis at alum.mit.edu>wrote:
> The behavior of tellsimpafter as you describe it sounds peculiar and we
> should fix it.
>
> Here is an example of the current behavior:
>
> tellsimp(integrate(f(x),x),g(x))$
> integrate(f(x),x) => no change (verb is evaluated, not simplified;
> returns noun)
> 'integrate(f(x),x) => no change (doesn't match noun)
> '(integrate(f(x),x)) => g(x) <<< matches; what use is this?
>
> It seems to me that there is no good reason to be defining simplification
> rules on verbs. Yes, I can construct scenarios where it would be useful
> (see below), but even if someone does that someday, I'd argue it is a very
> very specialized and unusual case. The usual case is application of
> tellsimp rules during general simplification of whole expressions, in which
> there should be no verbs at all (remember that simplification doesn't reach
> inside lambdas including function definitions).
>
> So I would suggest that tellsimpafter(f(...),...) should be interpreted
> as applying to the *noun* f. Same for any embedded functions, e.g.
> tellsimpafter(f(diff(x,y))...). The only argument I can think of against
> this is that if for some reason you *do* want to define a rule on a verb,
> you won't be able to.
>
> -s
>
> -------------
> Here's the unusual scenario where simplification rules on verbs would be
> useful. Suppose I'm writing a transformation system for Maxima programs
> (non-Maxima programs don't have such a thing as a noun/verb system...).
> For example, I might want to transform the code fragment (thru 3 do x)
> within a program to (x,x,x) ("loop unrolling<http://en.wikipedia.org/wiki/Loop_unwinding>;
> "). In that case, the pattern would have to match a verb, not a noun.
>
> On Sun, Nov 25, 2012 at 4:44 PM, Robert Dodier <robert.dodier at gmail.com>wrote:
>
>> On 2012-11-25, Stavros Macrakis <macrakis at alum.mit.edu> wrote:
>>
>> > 1) tellsimpafter attaches the simplification property to the *verb*
>> laplace,
>> > not the *noun* laplace (cf. noun and verb section of
>> > manual<http://maxima.sourceforge.net/docs/manual/en/maxima_6.html#SEC31
>> >),
>> > but the simplification needs to be on the noun. It is unclear whether
>> this
>> > is a bug; it is conceivable that one would want different
>> transformations
>> > on the verb form and the noun form.
>>
>> Well, I think tellsimpafter's treatment of nouns and verbs can only be
>> described as a bug. I'm tempted to say that a rule should always apply
>> only to either the noun or verb form, in the spirit of "you got what you
>> asked for". Here's a description of how it works at present (as
>> determined by reading the code & trying some examples):
>>
>> The treatment of noun and verb forms is slightly confused. If a
>> rule is defined for a noun (or verb) form and a rule for the
>> corresponding verb (or noun) form already exists, the
>> newly-defined rule applies to both forms (noun and verb). If a
>> rule for the corresponding verb (or noun) form does not exist, the
>> newly-defined rule applies only to the noun (or verb) form.
>>
>> Whatever we decide about tellsimpafter, we should ensure that tellsimp,
>> defrule, and defmatch act the same.
>>
>> > 2) when the laplace function returns a result, it marks it as simplified
>> > without giving the simplifier a chance to apply tellsimpafter rules.
>> This
>> > is a bug, which should be corrected.
>>
>> laplace constructs a lot of expressions with the SIMP flag, which should
>> just be struck out, right? laplace shouldn't mark expressions with the
>> SIMP flag.
>>
>> best,
>>
>> Robert Dodier
>>
>> _______________________________________________
>> Maxima mailing list
>> Maxima at math.utexas.edu
>> http://www.math.utexas.edu/mailman/listinfo/maxima
>>
>
>