If I understood your original problem properly, then the following

> f := CompSeq(params=[X],locals=[c11,c12,c21,c31], [c11 = 13*X+3, c12 = X-5, c21 = 12*c11-c12, c31 = c21^2, F = c31 + 2*c21 -c12]):
> convert(f, 'procedure');
proc(X)
local c11, c12, c21, c31;
   c11 := 13*X + 3;
   c12 := X - 5;
   c21 := 12*c11 - c12;
   c31 := c21^2;
   F := c31 + 2*c21 - c12
end proc

should give you an idea on how to proceed.

Why would one want to muck around with a feature that has not substantially changed since Maple V Release 4? Heresy! Next thing you know, you'll be asking for some automatic simplifications to be turned off - vintage Maple 1.0 stuff.

LegendreP(1,1,x) is even for x::RealRange(-1,1), so LegendreP(1,1,cos(x)) = LegendreP(1,1,-cos(x)). This "explains" the appearance of the I term. simplify is needed because it is not clear that such automatic simplifications are actually a good idea - the jury is still out on that. There are a host of reasons both for and against them. But one thing is certain: if an automatic simplification is present, there is nothing that can be done to prevent it from happening, which can be very frustrating. If it is absent, it is simple for a user to perform it. <shameless plug>I have written a paper on this issue, see my publications page, the paper titled Understanding Expression Simplification. Unfortunately, that was one of my early papers, so it suffers from being overly complicated, although the main ideas are still sound.</shameless plug>

LegendreP(1,1,x) is even for x::RealRange(-1,1), so LegendreP(1,1,cos(x)) = LegendreP(1,1,-cos(x)). This "explains" the appearance of the I term. simplify is needed because it is not clear that such automatic simplifications are actually a good idea - the jury is still out on that. There are a host of reasons both for and against them. But one thing is certain: if an automatic simplification is present, there is nothing that can be done to prevent it from happening, which can be very frustrating. If it is absent, it is simple for a user to perform it. <shameless plug>I have written a paper on this issue, see my publications page, the paper titled Understanding Expression Simplification. Unfortunately, that was one of my early papers, so it suffers from being overly complicated, although the main ideas are still sound.</shameless plug>

There used to be such a thing. It was first called "The Maple Technical Newsletter" (MTN), and then became a Birkhauser publication under the name "MapleTech" (at which time it became a fully refereed publication). MapleTech was alive from roughly 1994 to 1999, and unreconcilable differences between the various parties involved in its publication caused it to shut down at that time. The first issue of the (unrefereed) MTN was in early 1987. As a comparison, The Mathematica Journal's first issue was in 1990, and is still active today, but at only 2 issues per year, a 'volume' every 2 years. Of course, its impact factor (ISI) is 0.

Apparently the techno-geeks now form a small minority of effective buyers of Maple, so that marketing aimed at that segment is not very effective. Or so I've been told. Of course, Wolfram Research's web site(s) makes it rather obvious that they fundamentally disagree with this position. [Each word is a separate link]. On the other hand, there is mapleprimes. As far as I can see, there is nothing that even remotely compares in the Mathematica world. But then again, the amount of Mathematica documentation online is staggering.

If you don't escape your < and >, it causes havoc with the site, at least if you let the 'input format' on default (Filtered HTML). Only site administrators can go in and 'fix' your post(s) though.

It is usually known as oversimplify by the cognoscenti... It can be quite useful, but also very dangerous. What one would really want at this point is a localized inversion routine, as sort of partial-solve (rather like the many tools in the Student package for stepwise integration for example). But, as far as I know, no such tools are user-visible.

It is usually known as oversimplify by the cognoscenti... It can be quite useful, but also very dangerous. What one would really want at this point is a localized inversion routine, as sort of partial-solve (rather like the many tools in the Student package for stepwise integration for example). But, as far as I know, no such tools are user-visible.

I am not 100% sure of this, but I think the issue is one of numeric versus symbolic. More exactly, Maple does symbolic finding of discontinuities for expressions (like tan(x)) via discont and thus powerful commands like limit, series and solve. However, it does numeric finding of discontinuities in the case of procedures (like tan) via the much less powerful fdiscont (purely) numerical routine. [In this particular case, it would be relatively easy to hack up plot to recognize that this is not an arbitrary function, but a known one. But it would be just that, a hack.]

They are almost always the same, but it is possible that there are some strange corner cases where they differ, this I do not remember.

Maple is full of fun ways to do such things: (a,b) := map(LongFunctionName,[arg1,arg2])[]; or if you want to get very creative (a,b) := zip(apply,[LongFunctionName$2],[arg1,arg2])[];

To be honest, I really don't know where this is documented (other than in the What's New for Maple 6), but surely it is somewhere else. Look under "multiple assignment". Note that it is considered to be good style to use () around the left-hand-side of a multiple assignment even though, as you point out, it is unnecessary. This 'sophisticated' construction is easy to teach: you do it by observing what happens when you do (a,b) := (b,a); and you're pretty much hooked after that!

Maple has quirks, but as someone else has pointed out, this is not one of them. Ask yourself this: how would you plot (by hand, pencil-and-paper) a+m+x ?

Maple has quirks, but as someone else has pointed out, this is not one of them. Ask yourself this: how would you plot (by hand, pencil-and-paper) a+m+x ?