Re: [Maxima-discuss] rule issue

[Robert D. <rob...@gm...>]

On 2014-06-29, Richard Fateman <fa...@be...> wrote:

> Interestingly, if the correctness of the rule seems to depend on the 
> alphabetic order of the terms in the integrand. 
> Thus  changing it from   delta(u)* fn(u) to   gdelta(u)*fn(u)
> makes it work.

Yes -- in that case, the bug is not triggered.

> 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.

> 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.
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