If he's using Classic on Windows and Standard (and a Document Block in Document Mode), things like the above can happen too in Maple 10, where prints were swallowed up. I think that behaviour has been changed for 11. If I were doing this, I'd use indets() and combinat[cartprod] -- just so the code would be extensible to n variables.

If he's using Classic on Windows and Standard (and a Document Block in Document Mode), things like the above can happen too in Maple 10, where prints were swallowed up. I think that behaviour has been changed for 11. If I were doing this, I'd use indets() and combinat[cartprod] -- just so the code would be extensible to n variables.

Careful, the root ordering is only guaranteed to be in this order for polynomials. To be precise, the order is first by angle (so positive roots come first, negative second), then magnitude in case of ties. This is probably documented somewhere...

Careful, the root ordering is only guaranteed to be in this order for polynomials. To be precise, the order is first by angle (so positive roots come first, negative second), then magnitude in case of ties. This is probably documented somewhere...

subs should be buried in the appendix to the Advanced Programming Guide... Its semantics are weird, and users get befuddled by it at the strangest of times. Use the 2-argument eval instead. I would have written the above as

restart;  Digits := 14;

f := n*C^2/(C*(C+n*e*h));
g := 4*n*C^2/(2*C+n*e*h)^2;
pt := {C=100, e=1, h=2.8}:

P1 := plot(eval(f, pt), n=0..20, color=magenta):
P2 := plot(eval(g, pt), n=0..20, color=blue):
plots[display]([P1,P2]);

It makes changing the value of evaluation easier. Note that unapply is not needed at all here -- why did you think it was?

subs should be buried in the appendix to the Advanced Programming Guide... Its semantics are weird, and users get befuddled by it at the strangest of times. Use the 2-argument eval instead. I would have written the above as

restart;  Digits := 14;

f := n*C^2/(C*(C+n*e*h));
g := 4*n*C^2/(2*C+n*e*h)^2;
pt := {C=100, e=1, h=2.8}:

P1 := plot(eval(f, pt), n=0..20, color=magenta):
P2 := plot(eval(g, pt), n=0..20, color=blue):
plots[display]([P1,P2]);

It makes changing the value of evaluation easier. Note that unapply is not needed at all here -- why did you think it was?

I don't think this is quite what you want, but it might be closer:

plotit := proc(n::posint) local k;         
    plots[display](seq( seq( plot3d([a*cos(k*2*Pi/n+(i-x)),a*sin(k*2*Pi/n+i-x),3*x],  a=8..20,x=0..12), 
                         i=0..6,0.05), k=0..n-1),insequence=true):
end: 

But the idea is there -- you need to wrap things inside a procedure. You'll need to figure out how to assemble the animation in the way you want.

I don't think this is quite what you want, but it might be closer:

plotit := proc(n::posint) local k;         
    plots[display](seq( seq( plot3d([a*cos(k*2*Pi/n+(i-x)),a*sin(k*2*Pi/n+i-x),3*x],  a=8..20,x=0..12), 
                         i=0..6,0.05), k=0..n-1),insequence=true):
end: 

But the idea is there -- you need to wrap things inside a procedure. You'll need to figure out how to assemble the animation in the way you want.

I actually had the occasion to discuss implicit multiplication (and whether it was desirable) with Don Knuth once. He agreed that the following compromise (in Maple) might work: all inputs that are currently syntactically and semantically correct would be interpreted as they currently are. All others, ie all those that would eventually lead to an error, would be interpreted as implicit multiplication. This has the great advantage of being backwards compatible! Of course that does not actually help with cut-and-paste of output as input, because output mode can produce ambiguous results. These, IMNSHO, should be fixed.

I would guess that the two you show above are quite distinct. And your idea of using Maple's own examples as a test is a good one! I am pretty sure that could be automated too, to a point. One could automatically create worksheets with all of that input as 1D, and then manually switch all of those lines to 2D (ugh), and execute. Would that do it? Otherwise, one could probably write a more complex program that would 'script' the Java GUI (feeding it keystrokes) into entering all of that input into 2D more. Sure would be a good test! In your last paragraph, you identify some real hard issues with having multiples 'modes' of entry. I think you already know the answer to your questions though.

How do I get those nice labels in Standard? I have huge DAGs with lots of common sub-expressions, and I can't find out how to get the output that Classic gave me (which was much more compact, and what I wanted to see).

How do I get those nice labels in Standard? I have huge DAGs with lots of common sub-expressions, and I can't find out how to get the output that Classic gave me (which was much more compact, and what I wanted to see).

This might be something really nice to push out as a point release of Maple. It is nicely isolated, and also nicely "revertable" if something goes awry.

I would not start a new editor -- there are too many already! But many editors are highly customizable, and can host language-aware features very comfortably. Vim, emacs, jEdit, crimson, SubEthaEdit and of course Eclipse plug-ins, can all support a much richer interaction with Maple, and many of them out-of-the-box. The vim mode for Maple needs work -- that might be the one place where you'd get fastest reward for your efforts. Since you're already using it, why not continue in that direction? It is worthwhile checking out the comparison of text editors too.

You seem to be thinking imperatively -- like in the old days of C and Fortran. If you are going to re-assign all the entries, why does this matter at all? Maple has many other sources of overhead that make the above disappear in the noise. If, on the other hand, what you really want is to re-assign just a small part of your Array, then it might be worth it. I would still avoid the explicit loop unless actual profiling showed that to be a problem.

Tent[1..4] := Array(1..4,  i->unapply(christoffel[i]+v^i,v));

would re-assign only parts of the entries. The overhead of the extra Array is negligible.