posible bug - clashing variable names in integrals

2009/10/3 Leo Butler <l.butler at ed.ac.uk>

>
>
> On Sat, 3 Oct 2009, Nathaniel Virgo wrote:
>
> < Ok, sorry, yes, I think I understand this now.  So it's not a bug per se
> < that 'is' returns 'false' in that situation.
> <
> < It is, however, still annoying that it doesn't treat
> integrate(f(x),x,a,b)
> < in exactly the same way as integrate(f(y),y,a,b).  It should do because x
> < and y are bound variables in those expressions, so their name should not
> < make any difference in any situation.  This difference in the way it
> treats
> < these two expressions is likely to be a problem for a lot of the things I
> < wanted to use Maxima for.
>
> Again, in integrate, there is no such thing as a bound variable, because
> Maxima integrates an expression. What you are calling a bound variable
> may already appear elsewhere in your expression (as in the example I
> gave).
>

I don't understand that argument.  Yes, *if* the variable appeared elsewhere
in the expression then it might not be a bound variable, but in this case it
*doesn't* appear elsewhere in the expression, so it is a bound variable.  Or
at least, it should be.  integral(f(x),x,a,b) is not in any way a function
of x.  x is just the name of a variable that has been integrated over.  Its
name should not make any difference to how it is treated.

In the examples I gave I was assuming f was not defined prior to entering
the integral expressions, but I think that integral(f(x),x,a,b) should be
equivalent to integral(f(y),y,a,b) even in the case even if f has previously
been defined as

f(x) := x*y

as in your example.  The reason being that f here is defined as a function
of one variable, so it shouldn't really make sense to integrate f(x) with
respect to y.  To my mind it would make the most sense to say that
integral(f(x),y,a,b)=0, no matter how f is defined, because f has been
specified not to be a function of y.  The ability to make this kind of
inference would make Maxima's reasoning about integrals more powerful, and
from Barton's examples it looks like that's already how it works for sums
and lambda functions.

So with f defined as above I would say that

integral(f(x),y,a,b)  should give 0 because f(x) is not a function of y
integral(f(x),x,a,b)  should give y*(b-a) because y is a constant that
appears in the definition of f
integral(f(y),y,a,b)  should give y*(b-a) for the same reason.  The fact
that the integration variable has been given the same name is confusing but
not problematic.

If f is really meant to be a function of both x and y then it should be
defined as

f(x,y) = x*y

and then the two integrals  integral(f(x,y),x,a,b)  and
integral(f(x,y),y,a,b)  are syntactically different as well as
non-equivalent.

As I already said, it looks like this is how it already works for sums and
lambda functions, so this would just bring integration in line with that.
The opposite approach -- changing sums and lambda functions so they don't
work this way any more -- would just make maxima less powerful for no
reason, IMO.


All I want to do is to use Maxima to do proofs where factoring expressions
of the form

integral(integral(f(x),x,a,b)*g(x),x,c,d)

into

integral(f(x),x,a,b)*(integral(g(x),x,a,b)

is an important and frequent step.  See for example
http://en.wikipedia.org/wiki/Conditional_entropy#Chain_rule (you'll have to
mentally convert the sums into integrals, but it gives an idea of the sort
of thing I want to be able to do).  These kind of proofs appear all the time
in information theory.  Doing them by hand is laborious and error-prone,
which is really why I was looking for a computer algebra package in the
first place.  I don't want to do an explicit change of variables every time
I need to factor an integral in that way - it should just happen
automatically.

Nathaniel




> Incidentally, for the same reason, I believe that the behaviours that
> Barton described with sum and lambda are incorrect.
>
> Would 'changevar' be of any help for you? e.g.
>
> (%i85) A: integrate(f(x),x,a,b);
> (%o85) 'integrate(f(x),x,a,b)
> (%i86) B: integrate(f(y),y,a,b);
> (%o86) 'integrate(f(y),y,a,b)
> (%i87) B: changevar(B,part(B,2)-part(A,2),part(A,2),part(B,2));
> (%o87) 'integrate(f(x),x,a,b)
> (%i88) is(equal(A,B));
>
> Maybe 'equal' sh/could be extended by adding an option that allows the user
> to say that variables of integration/summation, etc. should be
> treated as bound variables.
>
> Leo
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>