For a few releases now, you can do

n2 := proc(l::nonnegint)
local z;
    unapply(-(-1)^l*diff(cos(z)/z,[z$l]), z);
end proc:

(i.e give the 2nd argument of diff as a list), and diff(f,[]) is the identity.

For a few releases now, you can do

n2 := proc(l::nonnegint)
local z;
    unapply(-(-1)^l*diff(cos(z)/z,[z$l]), z);
end proc:

(i.e give the 2nd argument of diff as a list), and diff(f,[]) is the identity.

The version above, even if it looks curried, does not actually compute anything when given l. The version below does:

n:=proc(l) local f, z;
   f := x -> cos(x)/x;
   if l=0 then unapply(-f(z),z)
   else unapply(-(-z)^l*(1/z)^l*(D@@l)(f)(z), z)
   end if;
end;

The version above, even if it looks curried, does not actually compute anything when given l. The version below does:

n:=proc(l) local f, z;
   f := x -> cos(x)/x;
   if l=0 then unapply(-f(z),z)
   else unapply(-(-z)^l*(1/z)^l*(D@@l)(f)(z), z)
   end if;
end;

You should make sure to forward this report to technical support (support@maplesoft.com). Maplesoft tends to take regression bugs (ie things that used to work but no longer do) quite seriously.

Ok, so the 2D parsing problem is incredibly hard. But 1.4s vs 0.073 is still a huge difference. The Maple documentation should really recommend strongly that programs be entered in 1D, and simple math expressions can be done in 2D. Let's hope that Maple 12 will contain a proper 'program' container (like tables and plots are mode-full containers) so that one can enter Maple programs in a decent way in the GUI. This has been a problem from day 1 of all Maple GUIs, programs are not treated seriously. And clearly many many maple users end up writing (small) programs.

Pi was originally discovered through physical means, but eventually people found that it was a much more fundamental constant. In fact, that Pi could be defined abstractly, outside any physical system. And that is where it became a constant on which various questions (like transcendence) could be asked. Now, maybe there is an abstract theory in which Planck's constant is not 'physical', and in which it makes sense to ask these questions. That would be very very cool.

If the explanation is that the underlying technology (Java) is not good enough for the task, then who is the idiot who did the technical feasibility study and concluded "yep, Java is suited for writing Maple's new GUI"? That cannot possibly be the official explanation, as it would be an admission of technical incompetence. If the explanation is that the current architecture of the GUI is such that this is inevitable, that would be admitting incompetence too. So the answer has to be: it is a bug, and it will be fixed. Note that the Eclipse project (a Java IDE, written in Java) has their own GUI toolkit for Eclipse, since they concluded that both AWT and Swing were too buggy to rely on. And unless you have a really powerful machine, Eclipse is an awful resource pig that is awfully slow.

In theory, I completely agree with you. In practice, this is harder than it sounds. First, Maple is currently not well architected to give you that kind of information in a structured way. Second, and more important, a lot of the algorithms that Maple uses are quite advanced, even when doing what looks like relatively simple tasks. So, if Maple were to tell you how a particular result is derived, you may not be enlightened at all, in fact you might have to go off and learn quite a lot of mathematics just to understand that algorithm. That is not necessarily a bad thing, mind you, but it might be rather unexpected! [I have posted about this before on this site, but can't find my post right now, or I would link to it].

That's one idea that would work. If you could have 2 kinds of stars (one for 'I like', one for 'remember this one'), that would be great.

What character encoding are you using? I try many, and in none of them did your post show up as anything but gibberish.

I have quite interested in the compilation facilities, so I am quite curious to see your test examples.

They did not show up in your post.

I left some of your code as comments below. Note that there is very little chance to get a useful closed-form solution for this. Maple may return a solution, but it will most likely be gigantic, and of little use. You probably want to make some of your parameters numbers. On the other hand, your probably has a lot of symmetry -- looks like some kind of symmetric quadratic form problem? There might be ways to use the symmetry to reduce the problem to something solveable. But this will require human ingenuity rather than brute force. restart;eq1 := e[0]^2+e[1]^2+e[2]^2+e[3]^2 = 1; A := Matrix([[e[0]^(2)+e[1]^2-1/2, e[1]*e[2]-e[0]*e[3], e[1]*e[3]+e[0]*e[2]], [e[1]*e[2]+e[0]*e[3], e[0]^(2)+e[2]^2-1/2, e[2]*e[3]-e[0]*e[1]], [e[1]*e[3]-e[0]*e[2], e[2]*e[3]+e[0]*e[1], e[0]^(2)+e[3]^2-1/2]]); A := 2*A; # vectorA := Matrix([a[1, 1], a[1, 2], a[1, 3]]); vectorA := Vector[row](3, i->a[1,i]); #vectorB := Matrix([[b[1, 1]], [b[1, 2]], [b[1, 3]]]); vectorB := Vector[column](3, i->b[1,i]); # eq2 := evalm(vectorA&*A&*vectorB) = 0; eq2 := vectorA . A . vectorB; #vectorC := Matrix*(1, 4, symbol = c); vectorC := Vector[row](4, symbol = c); # vectorE := Matrix([[e[0]], [e[1]], [e[2]], [e[3]]]); vectorE := Vector[column](4, i->e[i-1]); # eq3 := evalm(vectorC&*vectorE) = C; eq3 := vectorC . vectorE = C; eq4 := e[0]+e[1]+e[2]+e[3] = 0; # solve({eq4, eq3, eq1, eq2}, [e[0], e[1], e[2], e[3]]); solve({eq4, eq3, eq1, eq2}, [e[0], e[1], e[2], e[3]]);

I left some of your code as comments below. Note that there is very little chance to get a useful closed-form solution for this. Maple may return a solution, but it will most likely be gigantic, and of little use. You probably want to make some of your parameters numbers. On the other hand, your probably has a lot of symmetry -- looks like some kind of symmetric quadratic form problem? There might be ways to use the symmetry to reduce the problem to something solveable. But this will require human ingenuity rather than brute force. restart;eq1 := e[0]^2+e[1]^2+e[2]^2+e[3]^2 = 1; A := Matrix([[e[0]^(2)+e[1]^2-1/2, e[1]*e[2]-e[0]*e[3], e[1]*e[3]+e[0]*e[2]], [e[1]*e[2]+e[0]*e[3], e[0]^(2)+e[2]^2-1/2, e[2]*e[3]-e[0]*e[1]], [e[1]*e[3]-e[0]*e[2], e[2]*e[3]+e[0]*e[1], e[0]^(2)+e[3]^2-1/2]]); A := 2*A; # vectorA := Matrix([a[1, 1], a[1, 2], a[1, 3]]); vectorA := Vector[row](3, i->a[1,i]); #vectorB := Matrix([[b[1, 1]], [b[1, 2]], [b[1, 3]]]); vectorB := Vector[column](3, i->b[1,i]); # eq2 := evalm(vectorA&*A&*vectorB) = 0; eq2 := vectorA . A . vectorB; #vectorC := Matrix*(1, 4, symbol = c); vectorC := Vector[row](4, symbol = c); # vectorE := Matrix([[e[0]], [e[1]], [e[2]], [e[3]]]); vectorE := Vector[column](4, i->e[i-1]); # eq3 := evalm(vectorC&*vectorE) = C; eq3 := vectorC . vectorE = C; eq4 := e[0]+e[1]+e[2]+e[3] = 0; # solve({eq4, eq3, eq1, eq2}, [e[0], e[1], e[2], e[3]]); solve({eq4, eq3, eq1, eq2}, [e[0], e[1], e[2], e[3]]);