Do a topic search for "updates" in the help system and you'll find pages describing the changes in each new release, all the way back to Maple 4.0.

Actually that's not the same initial condition as you used before (u(x,0) = exp(x) instead of exp(-x)).

Note that the symbolic version of pdsolve doesn't find the most general solution, just  some  families of solutions that come from various methods (e.g. separation of variables).

Laplace transform is another method that can be used for this type of linear PDE.

Actually that's not the same initial condition as you used before (u(x,0) = exp(x) instead of exp(-x)).

Note that the symbolic version of pdsolve doesn't find the most general solution, just  some  families of solutions that come from various methods (e.g. separation of variables).

Laplace transform is another method that can be used for this type of linear PDE.

It worked for me inStandard Maple 12 under Windows XP.

The result of the c(op(p)) command is

9034025592132203400130472315137047931304333982705355711700373742042818299483584069391538998992267026[...157578 digits...]0481805685825907212126173342349538271583220175545069087458084181715591694879802681413018880069115454

In Classic, it did crash.  Strangely, however, on at least one occasion when the last command is replaced by

R := c(op(p));

it did not crash for me.  However, the result was different from the Standard result.  Thus R mod 1000000 turned out to be 330863. while in Standard it was 115454.

To put your system into correct Maple form, you need to replace asin by arcsin and pi by Pi.  Now solve, which tries to find closed-form solutions, is unlikely to do anything useful on a system involving both variables and trig functions of variables.  Instead, you can use fsolve.  Unfortunately, fsolve will only find one solution, but you can specify ranges for variables to try to find others.

> sys := {-Tf*0.005+1.1338-0.0027*cos(q1f+q2f+0)=0,
  -Tf*0.001+0.3618*(Pi-q2f)-1.2448-0.0046*cos(q1f+q2f)
-0.0076*cos(q1f+q2f)=0,
 Tf*0.006+1.1502*(1.3*Pi-q1f)-0.3618*(Pi-q2f)+0.2550
+0.306*cos(q2f)+0.153*cos(q2f+0.000001)-0.0664*cos(q1f)
+(-Tf*(0.009))/(0.029*cos(q1f-(q1f+arcsin((-0.0139*cos(q1f)
-0.0124)/0.029))))*(0.029*cos((q1f+arcsin((-0.0139
*cos(q1f)-0.0124)/0.029)))-0.0124*sin(q1f))/cos(q1f)=0};

> fsolve(sys); 

{Tf = 226.4070281, q1f = 1.805199844, q2f = -.9468030847}

> fsolve(sys,{Tf,q1f,q2f},Tf=-infinity .. 226.4);

(returns unevaluated)

> fsolve(sys,{Tf,q1f,q2f},Tf=226.5..infinity);

(returns unevaluated)

It looks like the solution above is the only one.

 More insight can come from graphing.  First of all, note that the first equation can be solved for Tf.

> Ts:= solve(sys[1],Tf);

Ts := 226.7600000-.5400000000*cos(q1f+q2f)

> sys2 := subs(Tf = Ts, sys[2..3]);

> plots[implicitplot](sys2, q1f = -10 .. 10, q2f = -10 .. 10);

This provides further evidence that there is a single solution (at the intersection of the two red curves).

To put your system into correct Maple form, you need to replace asin by arcsin and pi by Pi.  Now solve, which tries to find closed-form solutions, is unlikely to do anything useful on a system involving both variables and trig functions of variables.  Instead, you can use fsolve.  Unfortunately, fsolve will only find one solution, but you can specify ranges for variables to try to find others.

> sys := {-Tf*0.005+1.1338-0.0027*cos(q1f+q2f+0)=0,
  -Tf*0.001+0.3618*(Pi-q2f)-1.2448-0.0046*cos(q1f+q2f)
-0.0076*cos(q1f+q2f)=0,
 Tf*0.006+1.1502*(1.3*Pi-q1f)-0.3618*(Pi-q2f)+0.2550
+0.306*cos(q2f)+0.153*cos(q2f+0.000001)-0.0664*cos(q1f)
+(-Tf*(0.009))/(0.029*cos(q1f-(q1f+arcsin((-0.0139*cos(q1f)
-0.0124)/0.029))))*(0.029*cos((q1f+arcsin((-0.0139
*cos(q1f)-0.0124)/0.029)))-0.0124*sin(q1f))/cos(q1f)=0};

> fsolve(sys); 

{Tf = 226.4070281, q1f = 1.805199844, q2f = -.9468030847}

> fsolve(sys,{Tf,q1f,q2f},Tf=-infinity .. 226.4);

(returns unevaluated)

> fsolve(sys,{Tf,q1f,q2f},Tf=226.5..infinity);

(returns unevaluated)

It looks like the solution above is the only one.

 More insight can come from graphing.  First of all, note that the first equation can be solved for Tf.

> Ts:= solve(sys[1],Tf);

Ts := 226.7600000-.5400000000*cos(q1f+q2f)

> sys2 := subs(Tf = Ts, sys[2..3]);

> plots[implicitplot](sys2, q1f = -10 .. 10, q2f = -10 .. 10);

This provides further evidence that there is a single solution (at the intersection of the two red curves).

The conversion to floats may be difficult to avoid, because Excel lacks the distinction between integers and floats.  But as for the loss of the last column, that's an embarrassing bug.  It seems that the last column of any .xls file created by Export is always missing when Import brings it back into Maple.  Looking at some .xls files created by Excel rather than Maple, however, they seem to be imported correctly.  In fact, if you use Excel to open one of the .xls files created by Export, and save it in Excel, Import will open the saved file correctly.

What dsolve gives me (in Maple 11) is in no way "closed form": it involves a big RootOf an expression involving logarithms and trig functions, and simplifies (with combine) to

t(k) = ln(k)*k-1/2*ln(1+k^2)*k+1/2*k*ln(1/RootOf(k*sin(-1/2*ln(1/_Z^2)*k+_C2*k
-_C1-ln(k)*k+1/2*ln(1+k^2)*k)-cos(-1/2*ln(1/_Z^2)*k+_C2*k-_C1-ln(k)*k+1/2*ln(1
+k^2)*k)+_Z*(1+k^2)^(1/2))^2)-_C2*k

 I don't see this as an improvement over the result of solve, even if the values of _C1 and _C2 could be found.  By the way, k=0 might not be a good place to take the initial conditions, because of the singularity there in the differential equations (and presumably in the solution).

It seems the parser for 2D input in Standard doesn't like parameter type specifications in functions defined with ->.  

> f := (x::integer) -> x+1;

Error, invalid parameters for inline function

Also whoever wrote the error message doesn't seem to know what "inline" means in Maple.  Amazing!

But the work-around (besides using 1D input) is very simple: just define it using proc.

> p := proc(L::evaln) map2(cat,L,eval(L)) end proc;

It seems the parser for 2D input in Standard doesn't like parameter type specifications in functions defined with ->.  

> f := (x::integer) -> x+1;

Error, invalid parameters for inline function

Also whoever wrote the error message doesn't seem to know what "inline" means in Maple.  Amazing!

But the work-around (besides using 1D input) is very simple: just define it using proc.

> p := proc(L::evaln) map2(cat,L,eval(L)) end proc;

In this case I think it's Euler, not Ramanujan.  But maybe we could hope that Maple might know some of the simpler Euler products, e.g.

product(1-1/ithprime(i)^s, i=1..infinity) = 1/Zeta(s)

product(1+1/ithprime(i)^s, i=1..infinity) = Zeta(s)/Zeta(2*s)

assuming Re(s) > 1.

In this case I think it's Euler, not Ramanujan.  But maybe we could hope that Maple might know some of the simpler Euler products, e.g.

product(1-1/ithprime(i)^s, i=1..infinity) = 1/Zeta(s)

product(1+1/ithprime(i)^s, i=1..infinity) = Zeta(s)/Zeta(2*s)

assuming Re(s) > 1.

You're missing a right parenthesis.  Count them: three (, two ).

As for the other issue:

> H:=x-> if type(x,even) then print("Even"); else print("Odd"); end if:

does work in 1D input (both Classic and Standard), and 2D input in Classic but not Standard.  I guess that's a bug, but I wouldn't call it a serious one: arrow notation is really designed for a function that computes a single expression, rather than a complicated procedure with several statements.

You're missing a right parenthesis.  Count them: three (, two ).

As for the other issue:

> H:=x-> if type(x,even) then print("Even"); else print("Odd"); end if:

does work in 1D input (both Classic and Standard), and 2D input in Classic but not Standard.  I guess that's a bug, but I wouldn't call it a serious one: arrow notation is really designed for a function that computes a single expression, rather than a complicated procedure with several statements.

That 227 indicates that 227 bytes were written to the file.  However, before you look at the file, you should either close the file

> close("D:/Data/Data6/My_File8.txt");

or exit Maple.  The file should look like this:

4.000000 2.500000 1.000000 -0.500000 -2.000000
5.000000 3.500000 2.000000 0.500000 -1.000000
6.000000 4.500000 3.000000 1.500000 0.000000
7.000000 5.500000 4.000000 2.500000 1.000000
8.000000 6.500000 5.000000 3.500000 2.000000