@acer 

If the elementary rotation matrix around Ox is

Rx := u -> Matrix([[ 1,  0,       0      ],
                   [ 0,  cos(u), -sin(u) ],
                   [ 0,  sin(u),  cos(u) ]]);

etc, then the final rotation matrix corresponding to orientation=[a,b,c] is:

R:=(a,b,c)->Rz(a*Pi/180.).Ry(b*Pi/180.).Rx(c*Pi/180.);

But if we want to plot (manually) the rotated plot, we will have to use the inverse transform i.e.

R1:=(a,b,c)->Rx(-c*Pi/180.).Ry(-b*Pi/180.).Rz(-a*Pi/180.);

This also explains why the sense is clockwise.
So, from my point of view the problem is solved (I have tested it).

@Carl Love 

I have also noticed the clockwise sense of the rotations in my animation (yours are more artistic :-)). [BTW, the memory used is huge, so perhaps Explorer versions would be better].
I am puzzled that the help file mentions Euler angles, but in the wiki article about them, in all conventions the first and the third rotation axis are the same.

@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