@Michael_Ormstrup There are several easy ways to do that, but they all involve changing the way the arguments are input. If that is an option for you, let me know, and I'll expand on it. The problem with the way that the parameters are currently is that if you omit f2, giving it a default value 0, then a takes the place of f2. And who's to say that that doesn't mean that the user intended for f2 to be the horizontal line y = a?

Now here's a slightly-less-than-easy way to make 0 the default value for f2 and keep the user interface exactly the way it is now:

1. Change parameters 2 through 4 to different names: That is, change proc(f1,f2,a,b, {...}) to proc(f1,F2,A,B, {...}).
2. Add f2, a, b to the local variables.
3. Make the first actual statement (after the local declaration):
   (f2,a,b):= `if`(_params['B'] = NULL, [0,F2,A], [F2,A,B])[];

But, I recommend that you clean up the way that the arguments are passed, which would involve making a small change from the user's perspective.

d:= unapply(d(B), B):

D(d)(0);

Ordinarily, D would work on a procedure in exactly the way that you tried to use it. But, in this case it doesn't know what to do about the Determinant.

I don't think that you'll get any answer, or at least any useful answer, from solve except for certain specific values of R. For example,

solve(eval([Er1, Ez1], R=z1), {z1, rho1});

Although it is possible to convert a RootOf to a numeric solution, I recommend that you use fsolve directly; like this:

Sol:= r-> fsolve(eval([Er1, Ez1], R= r), {z1=0, rho1= 4/7}):
Sol(.3);

Z1:= r-> eval(z1, Sol(r)):
Rho1:= r-> eval(rho1, Sol(r)):
plot([Rho1, Z1], 0.1..2);

I am not a Mathematica user, so I can't make a comparison, but you can check Maple's ?Grid package and see for yourself if it's comparable. It was introduced in Maple 15.

The line in your codeyvals := op(2, pts1[i]), op(2, pts2[i]);needs to be changed toyvals := pts1[i,2], pts2[i,2];
As to why there was a change, I don't have the older Maple to check, so I can't be sure of this: I think that the points data in the plots in the older Maple were in listlist (or list of lists) form, and now they are in Matrix form. Using op to index into a Matrix doesn't work.

In addition to the other Answers, note that the capitalization of Maple commands matters. You mentioned linsolve, but your screen shot shows that you used Linsolve. They are different commands.

Like Jerome, I recommend that you use LinearSolve in the LinearAlgebra package.

If your function is a polynomial, then you can do this:

f:= randpoly([a,x]);

solve({diff(f,x)>0, x>0, a>0}, {x}, parametric= full, parameters= {a});

See ?solve,parametric and ?solve,ineq .

If your function is not a polynomial, then you should post it: There's a good chance that an ad hoc technique can be worked out.

If f(x,y,t) is an unevaluated function call, then you can do

e:= eval(e, y= NULL);

But if f is a defined function, then you'll need to provide a more-specific example before the question can be answered.

Here are your two plot commands:

plot([ns, r, t = 10^11..10^15], 0.8..1.2, 0..1);
plot([ns, r, t = 10^11..10^17], 0.8..1.2, 0..1);

So, the second plot has a range 100 times larger than the first, yet you are using the same view window. Both plots use 210 points for the whole range. So in the second plot, those points are spaced out much more.

It seems that when the assignment to a variable occurs in a Maple-language procedure, that variable does not appear in the Variables sidebar in the Standard GUI. But if the assignment occurs in a kernel procedure, then it will appear. For example,

P:= proc(x) x:= 3 end proc:
p(y);

                                              3
y;

                                     3

But y does not appear in the Variables list.

The procedures that you used, quo and rem, are Maple-language procedures; whereas iquo and irem are kernel procedures. So,

iquo(9, 3, 'r');

and now r appears in the list.

The answer is ` $`. Note that there is a space before the $. If you try to use this as a parameter, it will be treated as if it were the end-of-parameters marker $. But `$` (no space) can be used as a parameter.

Indeed, when the end-of-parameters marker is used, it is translated upon automatic simplification to ` $` as a parameter. You can see this in the prettyprint of a procedure:

P:= proc(x, $) end proc;

lprint(%);
proc (x, ` $`) end proc

You can also see it if you look at op(1, ...) (the parameter sequence) of the procedure:

lprint(op(1, eval(P)));
x, ` $`

Does the general form of the integrand suggest to you that a particular function might occur in the antiderivative (the answer)? Does it suggest a particular technique?

The problem is premature evaluation. The expression test(s) in the plot command is evaluated before s is given a numeric value. The cure is to delay the evaluation.

Download delay_eval.mw

You have a for loop defining the E equations. That loop begins at 3, so there is no E[2] equation. You need to start that loop at 2.

ex:= (1/6)*(-108+(12*I)*sqrt(1419))^(1/3)+10/(-108+(12*I)*sqrt(1419))^(1/3)+1:
simplify(Im(evalc(ex)));
                               0