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

Please post your actual code. The parametric curve expression that you gave is not at all like the plot in your Question. This is the plot of the curve that you gave:

@vidocq wrote:

I have exported second file to mpl and tried read "file.mpl" but it was not work.

No. Export the first file to .mpl and place the read command at the beginning of the second file.

@dena I'm using Maple 18 also.

To send me email, click on the More menu in the lower right corner. Then select Contact Author.

@dena Preben's code works for me. You should post your executed code so that we can diagnose what you are doing wrong. Here's my worksheet of it:

Download dsolve.mw

@casperyc asked:

First of all, I have to say that 'myfun' does call a lot of other functions and procedures and returns a single value. Does that mean I have to check every single one of them?

Yes, you have to check them all. But the list is alphabetical, so it's fairly easy.

If just to be safe, say I assume it does not qualify for multithreading and use the Grid option, is there going to be less efficient? Broadly speaking, how much difference?

The difference is huge. The Grid option starts a separate mserver on every processor and copies the entire memory of your base process to each one. Threads, on the other hand, does everything in the same memory space.

@Carl Love Here is a much smoother animation which shows that the analytic and numeric solutions are in perfect agreement and which eliminates the spurious "epi-waves" caused by the default coarse grid spacing.

restart:
PDE:= diff(u(x,t), t$2) = diff(u(x,t), x$2):
IBCs:= u(x,0)=sin(Pi/2*x)*exp(-x), D[2](u)(x,0)=0, u(0,t)=0, u(4,t)=0:
Sol:= pdsolve({PDE, IBCs}):
Sol:= subs(op([2,2,1], Sol)= n, Sol):  #Change _Z1~ to n, just for aesthetics
rhs(Sol);

Sol:= subs(infinity= 20, rhs(Sol)):
A1:= plots:-animate(plot, [Sol, x= 0..4], t= 0..8, frames= 200, thickness= 3):

Numeric solution:
Sol:= pdsolve({PDE}, {IBCs}, numeric, spacestep= .02):
A2:= Sol:-animate(t= 0..8, frames= 200, thickness= 3):
plots:-display(A1,A2);
By displaying the two animations together, we can see that they are in perfect agreement because there is only ever one line.