Don't believe everything you read. In this case there is no maximum: the function is unbounded, with y -> +infinity as X -> +infinity or -infinity. Suspiciously large results from Optimization almost always mean that Maple is not finding a maximum, but "chasing infinity" in a direction where the function is unbounded. There is also a local maximum, but it's near X = 0.5763495115.

Don't believe everything you read. In this case there is no maximum: the function is unbounded, with y -> +infinity as X -> +infinity or -infinity. Suspiciously large results from Optimization almost always mean that Maple is not finding a maximum, but "chasing infinity" in a direction where the function is unbounded. There is also a local maximum, but it's near X = 0.5763495115.

Those other inequalities are important!

> r1:= 1/4: r2:= 1/(2*(1+cos(theta)^2)):
  z1:= -9/(4*r^2+36): z2:= -z1:
  S1:= plot3d([[r,theta,z1],[r,theta,z2]],
    r=r1 .. r2,theta=0..2*Pi, 
    coords=cylindrical):
  S2:= plot3d([r1,theta,z], z =  eval(z1 .. z2, r = r1), 
    theta = 0 .. 2*Pi, coords = cylindrical):
  S3:= plot3d([r2, theta, z], z = eval(z1 .. z2, r = r2),
    theta = 0 .. 2*Pi, coords = cylindrical):
  plots[display]([S1,S2,S3], scaling=constrained, 
    style= patchnogrid, lightmodel=light1);
 

I assume this is supposed to be in cylindrical coordinates. Maple plots surfaces, but not solid regions. You can plot the surfaces z = 9/(4*r^2 + 36) and z = -9/(4*r^2 + 36) as follows:

> plot3d([[r,theta,9/(4*r^2+36)],[r,theta,-9/(4*r^2+36)]],
    r=0..10,theta=0..2*Pi, coords=cylindrical);

The region you want is between the two surfaces.

This needs some updating, which I'll try to do when I get around to it [anybody know a good supplier of round to-its?]. Meanwhile most of it is still usable in Maple 11 (though many of the bugs mentioned have been fixed).

This needs some updating, which I'll try to do when I get around to it [anybody know a good supplier of round to-its?]. Meanwhile most of it is still usable in Maple 11 (though many of the bugs mentioned have been fixed).

> lex:= proc(L1,L2) 
    local n;
    for n from 1 to min(nops(L1),nops(L2)) do
      if L1[n] <> L2[n] then return(evalb(L1[n] < L2[n]))
      end if
    end do;
    evalb(nops(L2) > nops(L1))
  end proc;
  sort(L, lex);

It would be nice if a "lexicographic order" for lists of integers were built-in, as it is for lists of symbols or strings, but apparently this is not the case. For lists of symbols, you could just say sort(L, lexorder). If all the entries of your lists are integers from 1 to 255 you could say

> Ls:= map(convert,L,bytes):
  Ls:= sort(Ls, lexorder):
  map(convert,Ls,bytes);

This comes from the way Maple deals with formal parameters in procedures. When the procedure is invoked, it first substitutes the actual parameters for the formal parameters in the body of the procedure, then executes the code in the body. This is substitution, not evaluation, so quotes don't have an effect. If you want the result to contain the (global) names x and y, you could use ':-x' and ':-y' instead of 'x' and 'y'.

The point is that arg(z) = Im(ln(z)) and the derivative of ln(f(t)) is f'(t)/f(t).

The point is that arg(z) = Im(ln(z)) and the derivative of ln(f(t)) is f'(t)/f(t).

An equation can certainly be equal to something (namely another equation), so there should be, and is, nothing wrong with blam = (foo = bar). The problem with blam = foo = bar is ambiguity, because = is a non-associative operator. Similarly for the other operators listed as non-associative in ?operators,precedence. On the other hand, one could argue that blam = foo = bar should be interpreted as (blam = foo) and (foo = bar), as that is common usage in mathematics. Even more convenient would be blam < foo < bar for (blam < foo) and (foo < bar).

Try it with this modification:

> S:=evalindets(Typesetting:-Typeset(p[gt]^`* `), string,
     StringTools[SubstituteAll],"`",""):
  t1 := textplot([Pi/2, 0.9, S]):
  ...

Note the space after the *.

Try it with this modification:

> S:=evalindets(Typesetting:-Typeset(p[gt]^`* `), string,
     StringTools[SubstituteAll],"`",""):
  t1 := textplot([Pi/2, 0.9, S]):
  ...

Note the space after the *.

{ } are the delimiters for a set. A set has no order. If you really want to make an Array or array, you could say

> Coords := Array([x,y,z]);
or
> Coords := array([x,y,z]);


Or you could make a Vector with
> Coords :=  < x,y,z>;

 
or a list with
> Coords := [x,y,z];

If it worked the way you would expect, what would you do if you really wanted x[i]? I think the idea of a "subliteral" is that it's a symbol containing a subscript. The subscript is a letter, not a variable. However, as others have mentioned it would be nice if there was a good way to create and modify such symbols under programmatic control, and then such issues could be addressed. But if you're making a symbol with keyboard and/or mouse, the symbol should be what you make it, with no evaluation.