For a 2D plot, you need exactly one 'free' variable [2 for 3D plots]. Of course, you need to remember that Maple can't read your mind, so anything that syntactically looks like a variable is a variable as far as Maple is concerned - even if you yourself think of it as an unknown constant! To figure out what free variables are in an expression, use indets(expr). If your expression has all sorts of (unevaluated) function calls in it, you might want to use select(type,indets(expr),'name') instead. Be wary: the intermediate Maple person will try indets(expr, 'name') instead, and be surprised when it does not always work as expected. I'll leave that as a puzzle for someone else to comment on!

For a 2D plot, you need exactly one 'free' variable [2 for 3D plots]. Of course, you need to remember that Maple can't read your mind, so anything that syntactically looks like a variable is a variable as far as Maple is concerned - even if you yourself think of it as an unknown constant! To figure out what free variables are in an expression, use indets(expr). If your expression has all sorts of (unevaluated) function calls in it, you might want to use select(type,indets(expr),'name') instead. Be wary: the intermediate Maple person will try indets(expr, 'name') instead, and be surprised when it does not always work as expected. I'll leave that as a puzzle for someone else to comment on!

First, you can get directly to the expression with one numerator via normal( sin(a+b) / cos(a+b), 'expanded'); If you want to apply something to the numerator and denominator, and normalize each separately, I tend to do (num, den) := (numer, denom)(expr1); expand(num/(cos(a)*cos(b))) / expand(den/(cos(a)*cos(b))); If you want to get fancy, you can do expr2 := [(numer, denom)(expr1)]; e3 := map(x->expand(x/(cos(a)*cos(b))), expr2); expr4 := e3[1]/e3[2]; Another trick is that if you want sin(a)/cos(a) = tan(a) just do subs(sin(a) = tan(a)*cos(a), expr1); Why? Well, in this case, automatic simplifications will work for you, and cancel out those extra cos terms! The random pulling of a -1 is very deeply ingrained in Maple. I remember trying to take that out, and having thousands of tests (for the huge automated test suite that runs every night) fail, some in spectacular ways. If people really are curious, I can try to explain it.

The form you gave will do the lookup at run-time for every time you wish to evaluate it. More efficient is f := unapply( add(X[m]*x^(L-m),m=1..L), x) with L := Dimension(X).

The form you gave will do the lookup at run-time for every time you wish to evaluate it. More efficient is f := unapply( add(X[m]*x^(L-m),m=1..L), x) with L := Dimension(X).

You need to be more precise, since plot(erf(x),x=-5..5) works fine for me. What exactly are you trying to plot that is failing?

You need to be more precise, since plot(erf(x),x=-5..5) works fine for me. What exactly are you trying to plot that is failing?

I asked earlier if there was an official policy about that on here, but never got an answer.

I asked earlier if there was an official policy about that on here, but never got an answer.

Thanks for the reminder, I had forgotten that often enough one can program in pointfree style in Maple (as well as in J, apl's successor). Actually, I remember making changes to evalapply myself to make this possible...

Thanks for the reminder, I had forgotten that often enough one can program in pointfree style in Maple (as well as in J, apl's successor). Actually, I remember making changes to evalapply myself to make this possible...

I meant that in general it is a good idea. Of course if your code is nice (such at the tp_ code), then Maple's type inferencer will be able to figure out on its own what the types of everything is.

I meant that in general it is a good idea. Of course if your code is nice (such at the tp_ code), then Maple's type inferencer will be able to figure out on its own what the types of everything is.

I know that type annotations are very useful - otherwise everything has to be done via type inference, and that has to be done conservatively. I don't know about globals; if they can be mapped to pure rtables, that's probably ok (but that is still just a guess), while I would rather doubt that other globals work 'cheaply'. In other words, other types of globals probably have to be copied in/out. In all cases, the more type information you give a priori, the more likely that CodeGeneration will be able to do the 'right thing'. And yes, Compile does go through CodeGeneration.

I know that type annotations are very useful - otherwise everything has to be done via type inference, and that has to be done conservatively. I don't know about globals; if they can be mapped to pure rtables, that's probably ok (but that is still just a guess), while I would rather doubt that other globals work 'cheaply'. In other words, other types of globals probably have to be copied in/out. In all cases, the more type information you give a priori, the more likely that CodeGeneration will be able to do the 'right thing'. And yes, Compile does go through CodeGeneration.