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

You have two problems, both related more to plotting in general than to the Explore command.

The first is that VEHQD assigns a value of 0.0 to local TD. That makes plots:-semilogplot throw the error message you see (which is then caught and rethrown by Explore).

The next problem is that the call to plots:-semilogplot prematurely evaluates its first argument, which is the call to QDCALC. That is resolved by wrapping that call to QDCALC in unevaluation quotes (single right-quotes). This is a common mistake.

Note that these two problems manifest themselves even if you invoke VEHQD outside of Explore, all on its own. For example, just computing this by itself,

VEHQD( 1.0 );

A sidenote on programming: At the start of your worksheet you call with(plots)  to load the plots package. And that allows the call to just semilogplot to work ok from within QDCALC. Better in my opinion is to instead add the line

   uses plots;

to the start of the QDCALC procedure, or to use the long-form fully qualified name plots:-semilogplot within that procedure. Your code can still work with the way you had it, though, and I did not make this change.

I also added the view option in that call to QDCALC, which I think makes for a nicer experience as the vertical range displayed is then common for the whole exploration. You can remove that is you don't prefer it.

Explore_VEHQD_1.mw

Lastly, you may indeed in future want a wrapping procedure like VEHQD for use with Explore. But that layer is not strictly necessary here. You could also do it with just,

Explore(plots:-semilogplot( 'QDCALC' ('TD' , RD), 'TD' = (1.0) .. (1000.0),
                           view = 0 .. 300 ),
        parameters = [ RD = 1.0 .. 30.0 ] );

acer