@acer 

The multiplication order seems to be Ok. And also the corrected description I gave. (Probably the Psi-Phi switch in the display is just an error).
This can be seen in the following simple animation:
 

cx:=plot3d([v, cos(u),sin(u)],u=0..2*Pi,v=0..10, color=red,style=surface):
cy:=plot3d([cos(u),v,sin(u)],u=0..2*Pi,v=0..10, color=yellow,style=surface):
cz:=plot3d([cos(u),sin(u),v],u=0..2*Pi,v=0..10, color=blue,style=surface):  L:=-15..15:
p:=(a,b,c) -> plots:-display(cx,cy,cz, 
orientation=[a,b,c], view=[L,L,L],labels=["x","y","z"],axes=normal,tickmarks=[0,0,0],
title=cat("theta=",a," phi=",b," psi=",c)):
a,b,c:=20,40,60:
p(a,b,c);
P:=NULL:
for k to c do P:=P,p(0,0,k) od: for k to b do P:=P,p(0,k,c) od: for k to a do P:=P,p(k,b,c) od:
plots:-display(P, insequence=true);

However I am not sure whether the senses ot the rotations are correct in the matrices. E.g. theta -> - theta or Pi - theta or something like that.
There are too many possibilities, so maybe someone from Maplesoft will be merciful ... [for the PROJECTION stuff too].

Best regards,
V.A.

 

@Markiyan Hirnyk 

The problem with these angles is that they are not intuitive (except theta).
If you keep e.g. theta and psi and play only with phi, it is not easy to anticipate the effect (at least for me). AFAIK everybody chooses theese angles by trial and error interactively.
I have used Explore to understand better the situation.
Maybe this could be useful for other users:

cx:=plot3d([v, cos(u),sin(u)],u=0..2*Pi,v=0..10, color=red,style=surface):
cy:=plot3d([cos(u),v,sin(u)],u=0..2*Pi,v=0..10, color=yellow,style=surface):
cz:=plot3d([cos(u),sin(u),v],u=0..2*Pi,v=0..10, color=blue,style=surface):  L:=-12..12:
p:=(a,b,c) -> plots:-display(cx,cy,cz, orientation=[a,b,c], view=[L,L,L],labels=["x","y","z"],axes=normal,tickmarks=[0,0,0]):
Explore(p(a,b,c),a=0..360, b=0..360, c=0..360); 

@acer 

Very nice!
Are there other structures in PLOT3D which are not documented? And why?

 

Actually it does not.
colorscheme=["xyzcoloring", (x, y, z)->0]);
should be red.

@Melvin Brown 

@student_md 

You will have to give explicit expressions for Xn, Fn.
(Not to mention the problematic diff(f,g) when g is not a symbol).

Otherwise this is just like asking: compute  limit(a(n), n=infinity) 
for an arbitrary a(n).

@John Fredsted 
I also guess that a straightforward answer is
M, Diag := LinearAlgebra:-JordanForm(A, output=['Q','J']);

@tomleslie 
You have used F(0)=0 instead of F(0)=1; the solution dsol4 does not verify Eq1 at 0
eval(Eq1, dsol4(0));
    .870507024896616 = 0
Actually if F(0)=F(1)=F(-1)=0 then F=0 is a solution.
If F is unique then F must be even, see the answer below.

@Christian Wolinski 

You should write a "debugable" version e.g. inserting print(...) in your strategic places. Then someone could execute it and post the results.
[Otherwise "someone" will have to "decompile" it in order to check the expected results].  

"The scope of the package is intended to cover basic precalculus mathematics"
exp(x+I*sin(I*t)) does not look like a function used in precalculus, so we should not expect to work without any problem.
But the fact that the keywords are so "irregular"  and inconsistent is indeed a problem.

@toandhsp 

Here it is solve's fault:

solve([x2/(x2+x5) = a1, x3/(x2+x5) = a2, x5/(x2+x5) = a3], {x2, x3, x5});
                    {x2 = 0, x3 = 0, x5 = 0}

On the other side  the first n-1 parameters are supposed to be "independent"
which is not the case:  log[10](2) + log[10](5) = 1.
lnrel(log[10](2), log[10](3), log[10](150));  #works

The code looks to me as unnecessarily complicated, almost obfuscated.
Please compare with the similar general solution in the provided link.

@Preben Alsholm 

@J4James 

691-694

@taro 

Actually remove expects the result of the procedure to be Boolean-"evaluable", i.e. creates a Boolen context.
This is not a problem because evalb(evalb(u)) = evalb(u).

@J4James 

See e.g.

Burden R.L.,Faires J.D. - Numerical Analysis, 9th Ed., Brooks/Cole 2011
(pseudocode provided, Maple oriented).