I really don't approve of the extensive, nested, use of operators in the manner in you have coded this (passing ony t for each call). It makes your computations repeat the same function calls many, many times. For example, just to compute three frames of the animatiion r1 is called about 580000 times.

There is also the problem of duplication where a vector-valued procedure (operator) is called 3 times inside another, outer procedure as all of, say, f(t)[1], f(t)[2], f(t)[3] .

And the nesting of calls within calls makes the overall effect on performance be cumulative.

It seems like a lot of time savings may be had by giving several of the key procedures option remember.

Better would be a complete rewrite, IMO, in another programming style. There may well be another factor of ten (or several) to be gained. But perhaps this helps you, for now. Double check the correctness of the numeric results, compared to the original, of course.

ClassicalTrajectoriesH2X_harm0.mw

acer

I think I see the problem, or part of it at least...

The convert(...,units,...) accepts an option symbolic=true which allows it to ignore the difference between m and m(radius) (ie. it allows convert to treat arclength and length as having the being the same kind of dimension).

But unfortunately that conversion requires that you know in advance what the target unit is, so it's not helpful here. And the combine(...,units) command doesn't accept a similar option.

It is possible to write a procedure that acts like combine(...,units) but which gets a similar benefit.

Download arcdeg2.mw

acer

Since it's often fun to have an alternate way...

restart; 

eqn := -g*t-vs*ln(r*t-m0)+vs*ln(-m0);

                        eqn := -g t - vs ln(r t - m0) + vs ln(-m0)

pars := [r=13100,vs=2550,g=9.81,m0=2.8e6]:

cond := convert( t::solve( eval( r*t<m0, pars ) ), relation );

                        cond := And(-infinity <= t, t < 213.7404580)

t<eval(m0/r,pars);

                                     t < 213.7404580

new1 := evalc( eval(eqn,pars) ) assuming t<eval(m0/r,pars);

                                          7
         new1 := -9.81 t - 2550 ln(0.28 10  - 13100 t) + 37855.08145 + 0. I

fsolve( new1=300, t=0..eval(m0/r,pars) );

                                     66.76469242 - 0. I

simplify(%,zero);

                                        66.76469242

new2 := simplify(new1,zero);

                                                   7
                  new2 := -9.81 t - 2550 ln(0.28 10  - 13100 t) + 37855.08145

fsolve( new2=300, t=0..eval(m0/r,pars) );

                                         66.76469242

fsolve( new2=300, t=-infinity..0 );

                                        -206.0184566

Try it like this, to protect aganst the situation that the unprotected names c or units have previously been assigned values.

evalf(Constant(':-c',':-units'));

That manner of coding applies to a variety of situations (including use of keyword option names, etc).

Note that those are single right-quotes, otherwise known as unevaluation quotes. Don't confuse them with single left-quotes, otherwise known as backticks or name-quotes.

The quotes protect against the situation that the name has been assigned. The colon-dash makes it use the global names, in case this call is made inside a procedure which happened to have the name in question also decalred as a local. There are lots of situations in which this handling is safest. But also note that Help page examples do not generally do it this way, even for names for which it may be applicable.

acer

Here are some ideas for making a pair of animations run simultaneously (and close to "in sync") in a pair of Plot Components.

double_animation_ideas.mw

I inserted the two Plot Components from the side palette. The supporting play/stop code could be hidden inside Buttons. (If you wanted to get really fancy you could both construct and insert the whole assembly programmatically. That seems like overkill, for now.)

I suppose that the simultaneous play might appear more synchronized if the animation whose frames were slower to render were the one that was updated first, if using the frame-by-frame method. I'd expect a 3D surface to usually render slower than a simple 2D curve. YMMV.

acer

There are two ways shown for doing progress bars in an example worksheet for Embedded Components that was new for Maple 2016. The Help Topic for that is examples,ProgrammaticContentGeneration 

If pressed I suspect I could make something similar work in Maple 14, but the background coding might look like shipbuilding with popsicle sticks.

I would guess that with that very many total iterations you naturally want to update the progress bar (only) modulo some large-ish number.

acer

Attached is all I could see as recoverable from the file you posted (just an empty subsection...), by closing off the various open-ended XML tags.

foo.mw

The corrupted file seemed (to me) to end midway through an (encoded) inlined image.

acer

This sets it up so that Q__T(...) a function call of anything will get coloured.

If you really want identiically Q__T(t) to be coloured differently than, say, Q__T(s) then please respond and I can adjust.

There are a few ways to go about this task. One want is to write a special new command which must be called (like one uses print) on the expression in order to colour some of its subexpressions. And that special command must be called each time one wants a new expression to be so coloured. Another way is to change the `print/...` routine which controls how particular function calls are prettyprinted, just once, after which no special call is repeatedly needed to get the colouring on new expressions -- it just happens. I've gone for the latter approach below.

In the actual Maple 2016.1 worksheet the name Q__T itself, as well as the "t" inside the arguments of Q__T in expr1 are also coloured, when the sheet is (re)executed. It's an artefact of this site's inline renderer that it doesn't all appear so below. It looks much nicer in my Maple 2016.1 Java GUI (although upon Close and ReOpen of the Worksheet the colouring of name Q__T itself may get lost, but not of its name arguments).

Colouring of the braces is harder, and I haven't done it. (There seem to be some version specific bugs around...) I suspect that it could be done by adding something open=mi(`&lpar`,color="blah") and the corresponding close= pair as extra arguments to the mfenced Typesetting calls.

Download Colorizer1.mw

I'd be interested in seeing the RHS of the shorter overall expression claimed by the OP.

Download simp3.mw

acer

One can indeed use unapply here, by using its numeric option. Doing so creates a procedure which returns unevaluated for nonnumeric arguments.

restart;

g := unapply('fsolve(a*y^2-sin(y),y=2)', a, numeric):

g(3);
                          0.3274097743

h := x -> x*sin(x):

h(g(1.0));
                          0.6738946032

h(g(2.0));
                          0.2224942708

evalf(Int(h(g(x)), x=1..2));
                          0.3917464163

restart;

ee := GAMMA(n-1/n)*GAMMA(1/n)/(n*GAMMA(n)) = 1:

ff := simplify( ee * GAMMA(n-1) / GAMMA(1/n) );

                                                          2
                                                         n  - 1
                                                   GAMMA(------)
                                                           n       GAMMA(n - 1)
                                             ff := ------------- = ------------
                                                     (n - 1) n      GAMMA(1/n)

Now, if the numerator and the denominator of the LHS of that were both equal to 1, and if additionally the RHS of that were 1, then we'd have a solution. And since GAMMA(1)=1 then we could look at the operand of the GAMMA call in the numerator of the LHS. Of course that is merely manual observation.

op(numer(lhs(ff)))=1, denom(lhs(ff))=1, subsindets(rhs(ff),specfunc(GAMMA),op)=1;

                                           2
                                          n  - 1
                                          ------ = 1, (n - 1) n = 1, (n - 1) n = 1
                                            n

solve( {n>1, n<4, % } );

                                                            1/2
                                                           5
                                                      {n = ---- + 1/2}
                                                            2

simplify( eval( ee, % ) );

                                                           1 = 1

acer

The problem in Maple 2016.1 is that those two calls to simplify are trying internally to apply a simplify(...,size) cleanup and a bug prevents that from working in the presence of the radical and the float coefficients.

So, while I have not yet attained an expression in Maple 2016 whose numeric integration matches the speed of Maple 18, I have figured out one way to improve the Maple 2016 experience by avoidng that bug. One aspect is to supply the applysimplifysize=false option to those two problematic simplify(...,Laguerre) and simplify(...,sqrt) calls to avoid the error message. Another attempt also applies simplify(...,size) successfully by first freezing the radical. These two attempts get speed reasonably close to the original when executed in Maple 2015.2.

It may be that some customized call to collect (on the frozen radical, or the cos(theta) , or the exp call, perhaps with optional simplify(..,size) applied to the collected coefficients) might do even better. If I find something I'll let you know.

Maple_numeric_speed_3.mw

acer

Download lplot.mw

That plot looks less jagged in Maple itself. This site doesn't render 2D plot curves very nicely.

Slower but also better is,

evalf(Int(f(x)*g(x,a),x=-infinity..a-1,digits=16,epsilon=1e-3))

acer

I'm not sure which version of Maple you have, so I don't know which new features of Explore you can use. You may or may not want to use the echoexpression=false option.

TestExplore_1.mw

acer

You don't need to actually assign the values fo the variable in order to utilize then in some subsequent computation. Sometimes it is more convenient to not make the assignments, so that you can still use the names (as unassigned names).

restart;

l2 := Optimization:-NLPSolve( t1*th-tl-3, {t1+th<=3, th-tl>=3, t1>=-2} );

                      l2 := [-15., [t1 = -2., th = 5., tl = 2.00000000000000]]

op(2, l2);

                           [t1 = -2., th = 5., tl = 2.00000000000000]

eval( t1-th*tl, op(2, l2) ); # utilizing the solution without assignment

                                     -12.0000000000000

t1, th, tl; # still unassigned

                                         t1, th, tl

But you can make the assignments, if you wish. Note that doing do may make it more awkward to subsequently manipulate expressions where you want to use the names as just unassigned names.

assign( op(2, l2) ); # force the assignment

t1, th, tl;

                                 -2., 5., 2.00000000000000                                                   

t1-th*tl; # utilizing the assigned names;

                                     -12.0000000000000

acer