A point on the surface of the unit sphere moves according to the differential equation diff(x(t),t) = `&x`(omega(t), x(t)). Hmmm... another case where the MaplePrimes prettyprinter falls down...

> with(VectorCalculus):
  X:= <x1(t), x2(t), x3(t)>;
  omega := <cos(t),sin(t),sqrt(3)>;
  des:= convert(diff(X,t) - omega &x X, set);
  ics:= {x1(0)=0, x2(0)=0, x3(0)=1};
  sol:= dsolve(des union ics);
  x3sol:= subs(sol, x3(t));

x3sol := VectorCalculus[`+`](VectorCalculus[`+`](VectorCalculus[`*`](8, 1/13), VectorCalculus[`-`](VectorCalculus[`*`](VectorCalculus[`*`](2, 1/13), sqrt(3)))), VectorCalculus[`*`](VectorCalculus[`+`](VectorCalculus[`*`](5, 1/13), VectorCalculus[`*`](VectorCalculus[`*`](2, 1/13), sqrt(3))), cos(VectorCalculus[`*`](sqrt(VectorCalculus[`+`](VectorCalculus[`-`](VectorCalculus[`*`](2, sqrt(3))), 5)), t)))) ... and another such case. Actually there seems to be a bug here: sometimes this dsolve command works, other times it returns nothing. The point will be back at (0,0,1) whenever x3(t) = 1 (since it stays on the surface of the sphere). Of course a glance at the result shows that x3(t) is periodic. But if you want to continue with Maple:

> _EnvAllSolutions := true:
  solve(x3sol = 1, t);

2*Pi*_Z1/(-2*3^(1/2)+5)^(1/2) Yes, it will be back there whenever t is a multiple of 2*Pi/(-2*3^(1/2)+5)^(1/2).

That seems to be a tough one: I think it's the automatic simplifier that wants to write 1/sqrt(2) as sqrt(2)/2. 1/sqrt(a) is OK:

> 1/sqrt(a);

1/sqrt(a) But:

> subs(a=2, %);

1/2*sqrt(2) Note that subs does not evaluate the result of the substitution, so it must be automatic simplification that is changing 1/sqrt(a) to 1/2*sqrt(2). One rather kludgy thing you can do is this:

> 1/sqrt(`2`);

1/sqrt(`2`)

First use

> evalf(yourmatrix,6);

to create a version of your matrix that actually has 6-digit entries (rather than just displaying 6 digits), then export that one.

Useful as Maple is, there are some things that are better to do with pencil and paper. This is especially true for questions of a more "theoretical" type, such as these. Of course, you could look at particular examples with Maple, e.g. for your first question, you might look at a general 3 x 3 matrix A (with real and imaginary parts of each entry as separate real parameters) and count how many independent equations you get from the real and imaginary parts of the entries of A.HermitianTranspose(A) - IdentityMatrix(3)

Maple doesn't know that x,y,z are the names for the coordinates. You need

> SetCoordinates('cartesian'[x,y,z]):

which is there in the help page.

If you're talking about numerical solutions, fsolve will work with Si as it will with any function Maple knows about. So for example

> fsolve(Si(x) + x = 2);

1.029350259 If you're talking about symbolic solutions, I don't think solve knows anything about the Si function, so the results will be expressed in RootOf form.

> solve(Si(x) + x = 2);

RootOf(Si(_Z)+_Z-2) which just means: some number Z for which Si(Z)+Z-2 = 0. This is not unreasonable, because (as far as I know) there is no "closed form" expression for that number.

Actually it's always true (for all square matrices, normal or not) that det(exp(A)) = exp(trace(A)). But I guess you should follow your instructor's hint... 1) If H is diagonal with diagonal elements h_i (the eigenvalues), then U is ... 2) If H = S D S^(-1), then U = S exp(iaD) S^(-1).

Your subject line provided the hint: use "piecewise". For example:

> f:= x -> piecewise(x = 0, 0, x^delta*sin(1/x));

The reason it doesn't come up with a result is that it can't find a closed-form expression for the sum (there probably isn't any). This has little to do with the question of whether it converges. You might try csum from my Maple Advisor Database (it says Maple 6-7-8-9-10, but you can use this in Maple 11 as well). After the Database has been installed (or the source file for csum has been read):

> csum((-1)^n/ln(n), n);

true indicating that this series does converge.

From the help page ?sum/details:

For divergent sums, the sum command may return infinity, -infinity, unevaluated, or a finite result correct in the sense of analytic continuation. This behavior can be changed by setting the _EnvFormal environment variable. By default, the _EnvFormal environment variable is unassigned. If _EnvFormal is assigned true, the sum command uses resummation methods to return a finite result for various classes of divergent sums. If _EnvFormal is assigned false, the sum command uses more convergence testing to detect divergence for infinite sums. It more often returns infinity, -infinity, or unevaluated for divergent sums. This may slow down the computation.

> _EnvFormal := false;
  sum(1/ln(n), n=2..infinity);

infinity

> normal(1/n - 1/(n+1));

1/(n*(n+1)) Or in the other direction

> convert(1/(n*(n+1)),parfrac,n);

1/n-1/(n+1) For the sum

> sum(1/(n*(n+1)),n=1..infinity);

1 Perhaps you were using 1/(n(n+1)) instead of 1/(n*(n+1)).

(b) is not true in the case a = 0.

I'm not sure what's going on here, but this is not the best way to define or plot a piecewise function. Also rather strange, and possibly related to the problem, is the way you're using "RootOf" a quadratic without specifying which root of the quadratic you mean. I might try it this way:

> Q:= piecewise(pa < 3/5*m+4/5, -1/2*sgt+1-sqrt(pgt),
   pa < 1.5, (1/4)*(4*slt-slt^2+pa^2-4*pa+4*plt)/(-pa+slt),
   -1/2*su+1-sqrt(pu));
 s1:=4/5*m+2/5:
 s2:=RootOf(3*_Z^2+(2*m-8*pa)*_Z-4*m^2-4*m+8*m*pa+4*pa-pa^2,
    index=1);
 p2:=  -(1/18)*(-24*s2*pa-36*m*pa^2-50*m*pa*s2-38*pa^2+8*pa^3
   +19*m^2*s2+24*m*s2+31*s2*pa^2-14*m^3+42*pa*m^2-38*m^2
   +76*m*pa-24*m+24*pa)/(2*pa-s2-m);
 p1:=4/25-4/25*m+1/25*m^2;
 Qp:= subs(pgt=0,sgt=pa-0.01,plt=p2,slt=s2,pu=p1,su=s1,
    m=0.5,Q);
 plot(Qp,pa = 0.6 .. 2, discont=true);

Try this:

  
> DEtools[rifsimp](convert([eq_0, eq_1, q(t) = (D@@6)(x[0])(t)],
    diff));

TABLE([Pivots = [-1+x[1](t) <> 0], Solved = [diff(x[0](t),t) = 2*x[0](t)/(-1+x[1](t)), diff(x[1](t),t) = -2*x[0](t)/(-1+x[1](t)), q(t) = (-224000*x[0](t)^4*x[1](t)+112000*x[0](t)^4-640*x[0](t) *x[1](t)^2-104832*x[0](t)^3*x[1](t)^2-14592*x[0](t)^2*x[1](t)^3 +104832*x[0](t)^3*x[1](t)+64*x[0](t)*x[1](t)^5+ 3648*x[0](t)^2*x[1](t)^4-34944*x[0](t)^3-320*x[0](t)*x[1](t)^4 -64*x[0](t)+3648*x[0](t)^2+34944*x[0](t)^3*x[1](t)^3 +141120*x[0](t)^5*x[1](t)+112000*x[0](t)^4*x[1](t)^2 +60480*x[0](t)^6-14592*x[0](t)^2*x[1](t)+640*x[0](t)*x[1](t)^3 +320*x[0](t)*x[1](t)-141120*x[0](t)^5+21888*x[0](t)^2 *x[1](t)^2)/(-1-165*x[1](t)^8+330*x[1](t)^7+55*x[1](t)^9 -55*x[1](t)^2+165*x[1](t)^3-330*x[1](t)^4+11*x[1](t) -462*x[1](t)^6+462*x[1](t)^5-11*x[1](t)^10+x[1](t)^11)]])

> Q := subs(%[Solved], q(t));

You can then substitute the numerical values obtained by your procedure into Q (but I hope you didn't really mean t=1/2 in your example, because you run into a singularity there).

First of all, that's a rational function, not a polynomial, because of the (s-pa)^4 in the denominator. But that's not important: the denominator will always be positive, so you want to check the sign of the numerator. The fact that factor doesn't do anything to the numerator probably means that it's irreducible. Factoring is not always useful for polynomials in several variables. Let's call the numerator of your expression N.

> N := (1/16)*(9*s^5-3*s^4*m-34*s^4*pa+12*s^3*m*pa
+46*s^3*pa^2-18*s^2*m*pa^2-24*s^2*pa^3+12*s*m*pa^3+s*pa^4
-3*m*pa^4+2*pa^5-16*s^4+64*s^3*pa-96*s^2*pa^2+64*s*pa^3
-16*pa^4+16*p^2*s+48*p^2*m-64*p^2*pa):

The degrees in p of the terms in N are 0 and 2:

> {seq(degree(t,p), t=N)};

{0,2} Look first at the terms of degree 2: these will dominate when p is large (and you have made no restriction on the value of p).

> N2:= factor(select(t -> (degree(t,p) = 2), N));

N2 := 16*p^2*(s+3*m-4*pa) Clearly this will be negative under your assumptions if p is real and nonzero. Just to show that Maple can see this too:

> signum(N2) assuming p > 0, pa > m, pa > s;

-1 On the other hand, let's look at the case p = 0.

> N0 := factor(eval(N,p=0));

N0 := -(pa-s)^4*(-2*pa-9*s+3*m+16)

> signum(N0) assuming pa > m, pa > s;

signum(2*pa+9*s-3*m-16) Maple can't come to any conclusion on whether this is positive or negative, because it's clear that no such conclusion is possible: under your assumptions 2*pa+9*s-3*m-16 could be either positive, negative or zero. And thus the same is true of your expression.