To answer your questions:

1) The evalf command uses remember tables to store computed results, so that it can quickly look them up instead of recomputing if given the same input at the same (or lower) Digits. But, in order to keep the amount of stored results manageable, the stored results may be cleared when a garbage collection is done.

This is similar to the behaviour you can get on your own procedures, when re-passing previous inputs, if your procedure has option remember,system . Well, the remember table behaviour can be similar, though the interplay with Digits is a special finesse that evalf gets from the kernel.

So the second time your example runs some results may be remembered and thus appear to be computed more quickly (because they are not all being recomputed!). But there is also the possibility that a garbage collection will occur, wiping out that benefit (and in older Maple versions causing a separate delay while it collects).

2) These floating point computations are done by default using software representations of floating point numbers. This is what allows Maple to do floating-point computations at high precision. There are several ways to make Maple use hardware double-precision floating-point numbers for this instead. See here for a brief read.

One of the key things worth noting in Axel's good Answer is that it can also be significantly better to run a whole procedure under a single call to evalhf than to make repeated calls to evalhf inside a loop.

acer

You cannot use Tabulate and Explore in the same paragraph or execution group as in that case they both write to the same Task region. The same goes for ImageTools:-Embed or anything else that uses DocumentTools:-InsertContent. 

This is a known limitation, documented to some extent in Maple 2016.

The above relates to making separate calls to Explore and Tabulate in the same execution group. Your particular example of a nested csll also cannot work (as is, at present) because Tabulate returns NULL and merely displays results. Tabulate is not returning a result which can be passed to Explore programmatically.

I give your question an up-vote because I like the implications that 1) Explore should be able to handle a grid of "explorations" (which might not all need to be plots), and 2) there should finer control over how plots:-display(Array(...)) or _ARRAYPLOT render, and with in Table Cells should at very least be sensibly aligned and respect PLOT sizes.

As things stand right now you can Explore a plots:-display(Array(...)) call, as you've suggested. But handling of sized plots doesn't work so well in that, and individual cell coloring is not supported, and cell alignment is wonky. Also, all cells get updated upon changed value of any exploration parameter. It would be more useful if the Explore command syntax allowed one to specify a grid (listlist?) of items to explore, including any of plots/expressions/images, each updatable only when only its own dependent parameters changed, and fully supporting individual cell alignment/shading.

acer

If your expression is assigned to name expr then try the command combine(expr, power) .

You might also take a look at simplify(expr, power) which does some additonal work (eg, grouping).

The commands combine(expr) and simplify(expr) will also work, for your particular example. But they can do more work in general, changing some other example in an additional way that might not be desired. The command combine(expr, power) might help get just the change you've described.

acer

In this previous answer I gave some code that allows you to enter phasors using 2D Math, and do some arithmetic with them.

In the following example I used the angle symbol from Maple's "Operators" palette, to enter the phasors in 2D Input mode. You could also put the red code that defines the angle object in your worksheet's Startup Code region (or load it into a .mla Library using the commands in the LibraryTools package).

As it stands here the code would also return a floating-point result (without having to invoke evalf) if both angles were given as floats such as 30.0 and 60.0. (I might improve that, to go all floating-point if all the arguments are numeric and any of them is a float...)

Download phasorex1.mw

Does anyone think that I should beautify this and put it on the Application Center?

acer

Something simple to get you started. You can make it more sophisticated, or efficient. For example you have a number of choices about how to handle lowercase versus uppercase.

restart;

CP:=proc(s::string,n::posint)
  local a1, a2;
  uses StringTools;
  a1:="abcdefghijklmnopqrstuvwxyz";
  a2:="ABCDEFGHIJKLMNOPQRSTUVWXYZ";
  CharacterMap(a2,Rotate(a2,26-n),CharacterMap(a1,Rotate(a1,26-n),s));
end proc:

CP("The quick brown fox jumps over the lazy dog", 23);

                             "Qeb nrfzh yoltk clu grjmp lsbo qeb ixwv ald"

CP(%, 3);
                             "The quick brown fox jumps over the lazy dog"

I edited the code above. Originally I had it so that you could pass your own alphabets, optionally, but hard-coded 26 instead of using length. Upon reflection I figure I'll let you make your own enhancements, since you write that it's a project. You should be able to make it more automatic and flexible. A module might be nice.

acer

You may be able to get lucky. If you assume that lambda3 and lambda4 are real and that polynomial P below is always nonnegative then it seems that you can show that the imaginary part of the eigenvalues is 0 as well as convert the eigenvalues to a form that does not contain I explicitly. Would that be enough for you? You may also try to establish that P>=0.

Note that just because I does not explicitly occur in an expression does not mean that under floating-point evaluation (with real values for the parameters) the computed imaginary part will be identically zero. You can still get imaginary float artefacts due to numerical round-off error.

I used 64bit Maple 13.01 for Linux here.

Download evalsreal.mw

acer

The series of floats from those BesselJ calls is not converging fast enough for the Levin's U method (internal to evalf/Sum) to accept it as converging.

For this example a crude additional acceleration -- consisting merely of accumulating terms in groups/chunks -- may tip the scales.

Here's the short story version:

restart;

evalf(Sum(Sum(BesselJ(0,(2*N-1)*Pi/4)^2/(2*N-1),
              N=10*(n-1)+1 .. 10*n),n=1..infinity));

                          0.7858522509

evalf[30](Sum(Sum(BesselJ(0,(2*N-1)*Pi/4)^2/(2*N-1),
                  N=10*(n-1)+1 .. 10*n),n=1..infinity));

                0.785852250894067175089762442407

Here it is with a procedure and a little more flexibility. The following was run on 64bit Maple 2016.0 for Windows 7. Mileage may vary by platform/release.

Download crudeaccel.mw

acer

You can use DocumentTools:-GetProperty instead of DocumentTools:-Do, to extract from a TextArea Component without having to use quotes in the TextArea Component.

The result from GetProperty will be a string, but it's simple enough to convert that to a name programatically. In this way the user of the interactive interface does not have to type in any name quotes.

(You could also guard against the user of your interactive interface inadvertantly typing it in it with extra quotes. But if the user typed it in with extra string-quotes then you'd also have to deal with that too if you wanted a name, even if using Do.)

Download text_extraction.mw

acer

Look at the help page for the LinearAlgebra:-GenerateMatrix command.

acer

If your original expression is assigned to expr then the following works for your example,

W:={a,b,c,u,v,w,psi,phi,theta,varsigma,tau,upsilon}:
L:={seq(w(t),w=W)}:
LL:=L union map(diff,L,t) union map(diff,L,t,t):
LLL:=map(`=`,{seq(seq(A*B,A=LL),B=LL)},0):
simplify(expr,LLL);

                     /  2      \               /  2      \       
             2       | d       |       2       | d       |       
            R  rho h |---- c(t)| Pi + R  rho h |---- w(t)| Pi = 0
                     |   2     |               |   2     |       
                     \ dt      /               \ dt      /       

If you don't want to type in all those names (and wish to use all names found for first arguments of diff, say) then,

T:=indets(expr,specfunc(diff)):
TT:=T union map2(op,1,T):
TTT:=map(`=`,{seq(seq(A*B,A=LL),B=LL)},0):
simplify(expr,TTT);

                     /  2      \               /  2      \       
             2       | d       |       2       | d       |       
            R  rho h |---- c(t)| Pi + R  rho h |---- w(t)| Pi = 0
                     |   2     |               |   2     |       
                     \ dt      /               \ dt      /

Those are not quick. I would think that there are far more efficient ways, by either calling simplify with few terms (eg. only those that appear), or perhaps by using repeated calls to algsubs (foldr?). This is just the first easy thing that came to mind

acer

Try shift-enter to get a new line for code (without execution). In particular try it with the cursor prompt lying at the end of the line (below which you want a newline).

F3 (even combined with F4) is not supposed to do what you're asking for here (in general).

acer

In Maple 2015 and Maple 2016 you can obtain a 2D density plot, respecting the colorscheme option, by discretizing and using the plots:-surfdata command.

restart;
xlo, xhi, ylo, yhi := -5, 5, -5 ,5:
m, n := 50, 50:
plots:-surfdata(Matrix(m,n,
                      (i,j)->sin((xlo+(i-1)/(m-1)*(xhi-xlo))
                                 *(ylo+(j-1)/(n-1)*(yhi-ylo)))),
                xlo .. xhi, ylo .. yhi, dimension=2, style=surface, axes=box,
                colorscheme = ["zgradient", ["blue", "green", "yellow", "red"],
                               zrange = -5 .. 5]);

which you may compare with, say,

plot3d(sin(x*y), x = xlo .. xhi, y = ylo .. yhi, view = -10 .. 10, grid=[m,n],
       colorscheme = ["zgradient", ["blue", "green", "yellow", "red"],
                      zrange = -5 .. 5],
       style = surface, lightmodel=none, orientation=[90,0,0], axes=box);

acer

If you are using the Standard (Java) GUI and you want the equation to be prettyprinted (2D Math) then try something like this,

EQ:= s^2-4*s+1+sqrt(u/Pi)=3;
Typesetting:-mrow(Typesetting:-mn("The Equation is:   ",color=black),
                  Typesetting:-Typeset(Typesetting:-EV(EQ)));

And within a procedure you could wrap that in a call to the print command, naturally.

acer

restart;

rule:=abs(''a''::algebraic)^2='''a'''^2:

applyrule(rule,abs(x)^2);

                                                              2
                                                             x

a:=1:

applyrule(rule,abs(x)^2);

                                                              2
                                                             x

applyrule(rule,abs(s+y)^2);

                                                                 2
                                                          (s + y)

myexp:=abs(548.477146186283171377723+radius_motor*q_mot_vec_2(t)-l_wire_0[2])^2;

                                                                                       2
     myexp := | 548.477146186283171377723 + radius_motor q_mot_vec_2(t) - l_wire_0[2] |

applyrule(rule,myexp);

                                                                                  2
           (548.477146186283171377723 + radius_motor q_mot_vec_2(t) - l_wire_0[2])

acer

I just posted an answer yesterday to a question about doing this for a BVP.

There I used the numapprox package to get a rational polynomial that approximated the integral well and evaluated very quickly within dsolve/numeric. I suspect that this will allow by far the fastest computation that other approaches (especially with repeated use of solving), and is often reasonably easy to set up.

You could use the same approach for your IVP, I believe. Or you could use a black-box known function approach. And since it's an IVP ODE you could also use the procedure option (but that last one is more complicated to set up.

Here is an IVP example that I just made up. (Here it seems easier than it was for a BVP, when not approximating the integral and allowing the numeric integrations to be deferred until the dsolve/numeric solution is run.) Of course the degree of accuracy that you'll be able to obtain for the numeric integral, and the specifics of the speed performance, will depend on your example (which you didn't post so far).

Download ds_numapprox.mw

acer