Notice how the mL and g in your axis label are in italic. But if you used :-min in the label then it would be typeset in upright (roman).

It would look better if all these unit symbols and abbreviations (prefixed or not) were typeset consistently. And one simple way to get that effect is to create the axis labels using the Unit() command.

For example, using your previous code,

plot(fprod(t), t = -2..2,
     labels = [typeset("Time (", Unit(min), ")"),
               typeset("Rate (", Unit(mL/(min*g)), ")")],
     color = "blue");

acer

Is this what you mean?

restart:

ode:=diff(x(t), t, t)+(1000*(x(t)^2-1))*(diff(x(t), t))+x(t) = 0:
sollistA:=dsolve({ode,x(0)=-1,D(x)(0)=-0.8},numeric,output=listprocedure):

# method 1, numerical differentiation, after dsolve. Not generally robust.
X:=eval(x(t),sollistA):
plot(t->fdiff(X(tt),[tt,tt],{tt=t}), 0..1);

# method 2, isolate higher derivative from the original ode, if you can,
# and evaluate each function on the right using the listprocedure.

rhs(isolate( ode, diff(x(t), t, t) ));
DDXA:=eval(%, sollistA):
plot(DDXA, 0..1);

# method 3, augment the original DE with an extra equation,
# and then use that function from the listprocedure.

sollistB:=dsolve({ode,diff(x(t),t,t)=ddx(t),x(0)=-1,D(x)(0)=-0.8},
                 numeric,output=listprocedure):

DDXB:=eval(ddx(t),sollistB):
plot(DDXB, 0..1);

acer

The first of these just happens to work (but you can also force it with a few `collect` calls and a mapped simplify...).

It might be possible to harangue the terms so that the "Nu" name appears at the left of each product. I didn't go there.

Download Polysimp.mw

acer

Without attempting to manipulate your procedure's body in order to deal with the numeric difficulties more gracefully...

Download trighplot.mw

acer

Just assign the result of plots:-display to P.

  P := plots:-display( P1, P2 ):

Then P is a structure that contains both. So then either of the following will once more show it.

  plots:-display( P );

  print( P );

Also, in an earlier question you mentioned animating, if I recall. If so then try,

  plots:-display( P1, P2,... Pn, insequence=true );

which again you can assign to a new name.

acer

See section 6.5 of the Programming Manual, under the subheading "The remember, cache, and system Options".

acer

You didn't provide values for a, D1, and D2. So I just made some up.

If you wanted you could also treat those as parameters (in the dsolve/numeric sense).

Below, I'll treat q as a parameter for dsolve. See here for details on that.

Download odecurves.mw

acer

The curve is almost flat in the given range of x=-4..4. So to get an idea of the qualitative aspects of the curve one can increase working precision (to deal with accuracy issues), subtract off the ostensibly constant part, and manually create tickmarks.

Download flat.mw

The method=_d01amc seems to work fast here, in Maple 18.02. That is a compiled NAG Library function designed for semi-infinite integrands.

This is a hint that the problem was in something like an attempt at either expanding the integrand or poking at it for discontinuities in evalf/Int's internal control mechanism. For similar problems seen in the past a workaround has often been to force a suitable method or to unapply the integrand to get an operator rather than an expression.

If you raise Digits to 15 in your original, and use 5 steps, then the results appear to concur with those from forcing this method.

I was also able to simplify the integrand more compactly.

I also changed your initial constants to exact values (ie. 1 rather than 1.0, etc). It's quite often better to keep floats out of things... as much as possible until after you've finished simplifying expressions.

Download int_question.mw

The printed results A[i,2] of the above, using epsilon=1e-8, were,

                       -1.06754466261525
                       -1.05325302242161
                       -1.03558981773781
                       -1.01386179523186
                       -0.987289540024826
                       -0.955029158917161
                       -0.916216297715231
                       -0.870041095327763
                       -0.815862074159109
                       -0.753362760097712

That ran very fast, in my Maple 18.02 on 64bit Linux.

And (only) raising Digits to 15 in your original with epsilon=1e-5, and using 5 steps, I got,

                       -1.05325301997235
                       -1.01386179283364
                       -0.955029156513430
                       -0.870041093087944
                       -0.753362758062382

acer

Download cotrule.mw

Now, did you also prefer to have cos(N*h)+cot(N*q+A)*sin(N*h) instead of sin(N*h+N*q+A)/sin(N*q+A) ?

acer

This is a very common mistake. The formal parameters A, omega, and k of your original procedure SW are not the same as the (in this example, global) A, omega, and k in the expressions W1, W2, and W.

Here are two ways to make it work.

restart;
with(plots):

W1:=A*cos(omega*t-k*x):
W2:=A*cos(omega*t+k*x):
W:=W1+W2:

SW:=(A,omega,k)->animate(plot,[eval([W1,W2,W],[:-A=A,:-omega=omega,:-k=k]),
                               x=-4..4,color=[red,green,blue],
                               scaling=constrained],t=0..5,frames=10):

display(SW(2,2*Pi,5),insequence);

AltSW:=unapply('animate'(plot,[[W1,W2,W],
                               x=-4..4,color=[red,green,blue],
                               scaling=constrained],t=0..5,frames=10),
               [A,omega,k]):

display(AltSW(2,2*Pi,5),insequence);

acer

If you have your heart set on using a RealRange, then you can test the condition using the is command. Note that if...then will utilize evalb in your original, which is insufficient.

evalb( 0.5 in RealRange(0,1) );

                                                0.5  in  RealRange(0, 1)

is( 0.5 in RealRange(0,1) );   

                                                          true

If you don't need to mess about with Open() end-points then you might find it simpler to do it as follows,

0.5>=0 and 0.5<=1;

                                                          true

If the RealRange is being passed to you as a result of another computation you could also try it like so. Again, this doesn't account yet for the Open endpoints cases -- if you have such then using is might be simpler,

r := RealRange(0,1):  # given elsewhere...

0.5>=op(1,r) and 0.5<=op(2,r);

                                                           true

acer

Download megawatts.mw

acer

I chose the height for the 2D part to be minz+(minz-maxz)*0.1 using the min and max of the 3D part. It has not meaning, in terms of the expression `ee` that is plotted as the surface. Change that if you wish.

Download surfcont.mw

acer

Inside your procedure which calls Color(), try either replacing that with ColorTools:-Color() , or add the line uses ColorTools; at the start of the procedure, or put that use...end use inside your procedure.

Does your procedure color_my_rgb call Color?

restart;

f:=proc(nm)
  local c;
  c:=Color(nm);
  c[];
end proc:

# This does not work.
use ColorTools in
  f("Orange");
end use;
                              Color("Orange")[]

restart;

f:=proc(nm)
  local c;
  use ColorTools in
    c:=Color(nm);
  end use;
  c[];
end proc:

f("Orange");
                         1.00000000, 0.64705882, 0.

restart;

f:=proc(nm)
  local c;
    c:=ColorTools:-Color(nm);
  c[];
end proc:

f("Orange");
                         1.00000000, 0.64705882, 0.

restart;

f:=proc(nm)
  uses ColorTools;
  local c;
    c:=Color(nm);
  c[];
end proc:

f("Orange");
                         1.00000000, 0.64705882, 0.

acer