MaplePrimes - answers and comments on Question, Error, (in simplify/tools/_zn) too many levels of recursion

Works in Maple 12-14

Preben Alsholm — Fri, 25 Jun 2010 10:05:55 Z

Except for one extra parenthesis (which just created a syntax error) Maple 12, 13, and 14 computed the integral without problem:

restart;
with(VectorCalculus):
X := r -> sqrt(2/Pi)*alpha*exp(-alpha^2*(r.r)):
a_0:=a* <1/2*sqrt(3) , 1/2>:
r:=<x,y>:
assume(alpha>0);
about(alpha);
eq1:=int( X(r-a_0) , x=-infinity .. infinity);

The last assumption on a variable overwrites one made previously. If you want to make additional assumptions on a variable then use 'additionally'.

However, if you assume that alpha is positive, then you are assuming that it is in the real range from 0 to infinity (see the output from 'about(alpha)' ), so there is no need for an additional assumption about alpha being real.

Without the VectorCalculus package you need to be aware that the inner product by default works in the complex domain:

restart;
X := r -> sqrt(2/Pi)*alpha*exp(-alpha^2*(r.r)):
a_0:=a* <1/2*sqrt(3) , 1/2>:
r:=<x,y>:
r.r;
eq1:=int( X(r-a_0) , x=-infinity .. infinity):
simplify(eq1) assuming real;
#The following syntax can be used in Maple 14:
simplify(eq1) assuming real,alpha>0;

Preben Alsholm

curious;

otherworld314 — Fri, 25 Jun 2010 10:20:59 Z

Thanks for your reply, I took a look at it again, i just copied and pasted what you wrote, and it did the integral perfectly. Then I noticed that my original a₀had been replaced by a_0; I made this change and once again the program gave me the same error. Why does placing a₀give me an error, while a_0 does not?

_Thanks;

a[0] vs a_0 when a occurs

JacquesC — Fri, 25 Jun 2010 17:55:30 Z

@otherworld314 it's a long standing issue with Maple: in its data-structures, a is seen as being 'part of' a[0] (because it occurs in a[0], syntactically). Sometimes Maple gets confused by this, thinking there is a relation between a and a[0] -- which in all honesty, may or may not be there in the user's mind. It depends on the application. a and a_0 on the other hand are 2 completely different 'names', which are entirely unrelated.

Of course, the error you get points to a bug. But I would be willing to bet that this bug is caused by the unresolved design issue which I outlined above. This bug can probably be patched, but there are many many more of its ilk in Maple.

Best advice: don't mix names and indexed-names in the same expression. You'll upset Maple if you do. The end result will mostly be frustration on your part...

simplified version

Alejandro Jakubi — Fri, 25 Jun 2010 20:10:56 Z

@JacquesC

This is a simplified version of this bug:

a[0]:=a:
simplify(a);

Error, (in simplify/table) too many levels of recursion

Tracing it, I see that simplify/table and simplify call each other many times.

From the user point of view, I find that the main problem with indexed names is not its fragile nature, but that its usage is promoted in some areas of the documentation.

a 2D corollary

pagan — Sat, 26 Jun 2010 08:18:50 Z

@JacquesC A 2DMath corollary might be: don't mix subscripted names and their non-subscripted base name in the same expression (since by default subscripted names are indexed names).

@pagan very curious, I will be more

otherworld314 — Sat, 26 Jun 2010 22:13:01 Z

@pagan

very curious, I will be more careful from now on with the names of the vectors.

Thanks