Re: [Maxima-discuss] rule issue

[Richard F. <fa...@be...>]

On 6/29/2014 3:17 PM, Robert Dodier wrote:

  <snip>
>> 3. Check that arg 2 is a symbol.  locally bind it to u.  That is u:z .
>> else fail  ;********important, not done so early by matcher**********
> Yeah -- at present, the matcher considers arguments only in the order
> they are given. I've run into exactly this problem in another context
> (rules for Z-transforms). The general problem, as you know already, is
> that the matcher has no back-tracking capability.
Introducing backtracking adds capabilities but potentially horrendous 
inefficiency.  Perhaps the
solution here is to introduce one of the (lisp-source-code) matching 
programs that are
around.  One that I wrote for "MockMMA" looks very much like the 
Mathematica (tm)
matcher.  However the surface syntax is quite different -- the 
declarations are kind of in-lined
in the pattern.  Anyway, it has backtracking, and could be added.  I 
view it as an alternative
not a replacement.  There's also Mathics, for people who like 
Mathematica's pattern matching
but don't want to pay

Another solution that simplifies the pattern matching is to rearrange 
the arguments so they
can be matched left-to-right.  That is do this:

rule1:   change  integrate(a,var,low,high)    to integrate_var(var, a 
low, high).

This means that the pattern matcher can look at the argument "a" to see 
how the
particular variable var occurs in it without "guessing" what var might be...
All the other rules operate on  integrate_var(var,  ....)
except maybe one that re-arranges the arguments to the conventional order.

No backtracking needed to do this.

>
>> For example,  integrate(delta(z)*foo(a,z),z,minf,inf)   should probably
>> return foo(a,0)   but it won't.
>> neither will this work...  integrate(delta(z)* foo(z)*bar(z),z,minf,inf)
>> or
>>     integrate(delta(z)*foo(bar(z)),   ...
> Well, the rule 'integrate(delta(u)*fn(u), u, ...) --> fn(0) can't handle
> those, because fn must have exactly one argument and it must be u.
This is true. Your rule is much better, in addition to being simpler!  
I'm not sure it does a good enough job to
cover all the interesting cases. And of course if we really want to 
allow inf, und, etc, what do we
do if someone starts to ask for free-floating delta functions not inside 
integrate()?

Here's a case that I assume would be of some interest, and not covered...
   integrate(delta(z)* delta(z-1)* f(z) ,....  ) .  But I don't use 
these things myself.

RJF

> The reformulation I gave can handle them:
>
>    (%i1) display2d : false $
>    (%i2) matchdeclare (aa, all, uu, symbolp) $
>    (%i3) simp : false $
>    (%i4) defrule (r1, 'integrate(delta(uu)*aa, uu, minf, inf), subst(uu=0, aa)) $
>    (%i5) simp : true $
>    (%i6) r1 ('integrate (delta(z)*foo(a, z), z, minf, inf));
>    (%o6) foo(a,0)
>    (%i7) r1 ('integrate (delta(z)*foo(z)*bar(z), z, minf, inf));
>    (%o7) bar(0)*foo(0)
>    (%i8) r1 ('integrate (delta(z)*foo(bar(z)), z, minf, inf));
>    (%o8) foo(bar(0))
>
> r1 doesn't have the bug in it, so these will work even without the bug
> fix.
>
> best
>
> Robert Dodier
>
> __________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss