Listen to Jakubi. He is absolutely correct. It is hubris for Maple to think that quality typesetting can be attained by mouse clicking one's way through pallates.

  When `#mi( "V" )` ( with extra  spaces )  gives a diferent result from `#mi("V")`, you know you are in big trouble.

Earlier in the thread there is a reference to the "Typesetting [ Typeset ]" help page-note the redundant spaces.

I read it. Read it for yourself from a critical perspective. Does it really tell you anything useful at all? It includes one stupid example that  deals  with a subscript on a Bessel function.  The help page has some links, but by the time you follow them you feel like the poor fish named Dory in the movie "Finding Nemo." And from this we are supposed to infer the power and insightfullness of the Maple typesetting package?

Give us LaTeX support, otherwise the product will wither away.

You might find this thread informative.

http://www.mapleprimes.com/forum/poorqualitygraphicsexportedeps

I just don't like all of the clicking and atomic identifiers and contortions you need to use to jazz up Maple graphs. I still prefer psfrag and think the result is better because LaTeX gives you so much more control, without mousing around.

1. Decent LaTeX support for creating documents. The Maple document mode is not a sustainable nor is it universal. The industry standard is LaTeX, and Maple fonts are ugly.

2. A decent and consistent reconciliation between the two input modes. Having two parsers is insanity, and it has created too much confusion, if it has not killed the product.  Everybody is confused about

Classic/Standard/2D-Input/Maple-Input.

3. Support for Classic.

4. Fix the bugs in "solve". Why is it taking so long? Does it have to to with Groebner? My research colleagues are forced to use Maple 9.5 because the bugs introduced in solve after 9.5 have not been fixed. Maple should strive to be a research tool, not a substandard document creation tool.

Thanks Matt, this worked.

I knew that Mapleprimes would probably come through before technical support could. I did report the problem, and I did receive an email saying that they would respond in a timely fashion, but...

If you get help by

?plot3d[coords]

you will see an example mentioning z_cylindrical coordinates:

addcoords(z_cylindrical, [z, r, theta], [r*cos(theta), r*sin(theta), z]);

Cylindrical coords are set up for r=f(theta,z).

If you have z=f(r,theta), then you need z_cylindrical coords.

But since conventions vary--for example..f(theta,z) or f(z,theta)-it seems most straightforward to use

plot3d( [x(u,v),y(u,v),z(u,v)], u=a..b,v=c..d). This way you will always know what you are doing. If you jump in and use a packaged coordinate system such as coords=cylindrical, you might be perplexed until you unravel things by reading the help screens.

If you get help by

?plot3d[coords]

you will see an example mentioning z_cylindrical coordinates:

addcoords(z_cylindrical, [z, r, theta], [r*cos(theta), r*sin(theta), z]);

Cylindrical coords are set up for r=f(theta,z).

If you have z=f(r,theta), then you need z_cylindrical coords.

But since conventions vary--for example..f(theta,z) or f(z,theta)-it seems most straightforward to use

plot3d( [x(u,v),y(u,v),z(u,v)], u=a..b,v=c..d). This way you will always know what you are doing. If you jump in and use a packaged coordinate system such as coords=cylindrical, you might be perplexed until you unravel things by reading the help screens.

This is a clever approach. Nice!

I keep thinking that it would be so nice to be able to turn off automatic simplification. With the original expression 2/sqrt(n+2)-2/sqrt(n+3), I suspect that automatic simplification converts the difference into a quotient, thereby blinding Maple to the telescoping quality of the series.

But your approach cleverly works around automatic simplification.

This is a clever approach. Nice!

I keep thinking that it would be so nice to be able to turn off automatic simplification. With the original expression 2/sqrt(n+2)-2/sqrt(n+3), I suspect that automatic simplification converts the difference into a quotient, thereby blinding Maple to the telescoping quality of the series.

But your approach cleverly works around automatic simplification.

Naby,

You asked for the maximum value of T. As I pointed out, you can find this algebraically, without solving any differential equations.

If you also want to find the value of t for which this value is attained, it seems you need to analyze numerical solutions to the system of differential equations. This requires some work.

Naby,

You asked for the maximum value of T. As I pointed out, you can find this algebraically, without solving any differential equations.

If you also want to find the value of t for which this value is attained, it seems you need to analyze numerical solutions to the system of differential equations. This requires some work.

I copied and pasted your two lines for $x1 and $y1 in MapleTA 3.01 and they work fine for me.

By the way, you should probably alter your first line as follows:

$x1 = maple("randomize(): RandomTools[Generate](list(distribution(Normal(0,2)),10))");

otherwise you will always get the same list of random numbers.

I copied and pasted your two lines for $x1 and $y1 in MapleTA 3.01 and they work fine for me.

By the way, you should probably alter your first line as follows:

$x1 = maple("randomize(): RandomTools[Generate](list(distribution(Normal(0,2)),10))");

otherwise you will always get the same list of random numbers.

I guess one possibility is

factor(x^3-1,complex);
identify(%);

This treats all three roots as equal partners.
Obviously this is a solution with shortcomings!

A reason why factor should behave this way is because 1 is also the cube of two other numbers besides 1....(-1+sqrt(3)*I)/2 and its conjugate.

a priori, it is not clear that 1 should be preferred cube root of 1.

I see what is unsettling, but I can see a couple of ways to argue that Maple's response is not absurd.

For example, RealRange(-infinity,infinity) could be understood to be the set of real numbers x such that -infinity<= x and x<= infinity. Since infinity is not a real number, RealRange(-infinity,infinity) is equal to RealRange(Open(-infinity),Open(infinity)).

Another tack is to realize that topologically, R is simultaneously an open interval and a closed interval.