@geischtli The main tool to use is plottools:-scale. This operates on a frame after it has been created by plot3d. In the code below, I take the fourth and final frame from your animation, l(4), and put it on the same scale (same axes) as the first frame. Then I display these in a simple two-frame animation:

x1:= -2..1:              y1:= -1.5..1.5:     #first frame axes
x4:= -0.82..-0.7:   y4:= -0.2..-0.08: #last frame axes
L(4):= plottools:-scale(
     l(4), #first frame from your code
     (op(2,x1)-op(1,x1))/(op(2,x4)-op(1,x4)), #scale factor for x
     (op(2,y1)-op(1,y1))/(op(2,y4)-op(1,y4)), #scale factor for y
     1, #don't change z
     [(op(1,x4)+op(2,x4))/2, (op(1,y4)+op(2,y4))/2, 0] #central point of last frame
):

plots:-display([l(1), L(4)], insequence = true);

Unfortunately, the tickmarks are the same on each frame. I don't think that this can be changed. The ordinary tickmarks option will not correct this: The tickmarks of the last frame are applied to all frames once it's animated.

@sarra It's a periodic function, so does the actual interval matter as long as the width is correct? Here's a plot of Markiyan's Fourier Series for the convolution:

Pi/2+Sum(2*((-1)^i-1)*cos(i*x)/i^2/Pi, i= 1..infinity);

plot(Re(value(%)), x= -2*Pi..2*Pi);

(Can't upload plots now. But you can generate it from the code above. It looks like the correct convolution.)

Are you trying to plot a surface or a curve? complexplot3d is a command that plots a surface. Look at ?complexplot3d . There are four calling sequences. Which one were you trying to emulate?

@itsme Looking at the first few lines of showstat(Grid:-Map) and executing the code below shows that it behaves differently depending on whether the first argument is a named procedure or an anonymous procedure. This is because of the "last name evaluation" property of named procedures. (The issue is not really the use of the arrow, although the most common anonymous procedures are arrow expressions.)

debug(Grid:-Map):
Grid:-Map(x-> x^2, [1,2,3]);
f:= x-> x^2:
Grid:-Map(f, [1,2,3]);

Certainly this should be considered a bug since the help page ?Grid,Map shows examples with anonymous procedures.

There is a minor anomaly with the pizza problem. I wonder if MapleTA can resolve it. I repeat the problem here for convenience.

A group of 11 male and 13 female students is planning to go out for pizza. If 82% of the male students go and 62% of the female students go, find the probability that a random student who goes out for pizza is female.

The "expected" answer, judging from the multiple-choice answers, is

(.62*13)/(.62*13+.82*11) = 0.4719.

However, the realistic answer uses a whole number of males (.82*11 = 9) and females (.62*13 = 8) and is thus

8/(8+9) = 0.4706,

which is not one of the choices. Can MapleTA automatically adjust the answers to reflect this? It would just involve using Maple's round function. This anomaly also illustrates the inherent problem of requiring more significant digits in the answer (4 sig. digits) than were provided in the problem data (2 sig. digits).

I also wonder if MapleTA was used to include the drawing of the pizza to the right of the problem.

You may have a problem displaying 3d plots. Try this:

plot3d(0, x= 0..1, y= 0..1, axes= boxed);

@Preben Alsholm 

This avoids the step of having to substitute z = exp(2*I*x).

S:= -ln(2)+Sum((-1)^(n+1)/n*cos(2*n*x), n= 1..infinity);

expand(simplify(evalc(Re(value(S))))) assuming cos(x) > 0;

Make sure you also change pi to Pi. This is necessary in Maple in order for it to interpret the symbol as the mathematical constant.

@ecterrab Note that the OP wanted a real and b imaginary.

What input gives you the error message in your title, "too many levels of recursion"?

@ecterrab Sure, I would've rather used dchange than the seemingly artificial hack of switching to integrals. But it seems that as it's currently implemented, expand does not work on Sums, even though there is an `expand/Sum`.

@sharena2 The command (in the last line) should be plot, not plots.

@mehdi jafari The problem is that the symbolic sum returned by the symbolic integration is wrong.

@lemelinm Yes, I got that plot. But I don't see the connection between that plot and the plot in your original Question.

@itsme The bug is not in the numeric summation. You can replace the infinity upper limit of summation with a finite value to show that the numeric summation is correct.