@waseem The purpose of procedure H is to temporarily freeze the factors that are nontrivially polynomial in r, so that they don't get expanded.

A simpler procedure than I had above is just this:

H:=proc(ee)
  subsindets(ee,And(polynom(numeric,r),`+`),freeze);
end proc:

somesimplification2.mw

@gal Please upload a short Worksheet or Document that demonstrates the problem and attach it to a Reply/Comment.

You can use the green up-arrow in the Mapleprimes editor to upload an attachment.

@Ronan In the unix world it is an old convention to give subdirectories 3-letter names like bin, doc, lib, src, tmp, etc.

The name "src" stood for source.

But it's rather arbitrary.

My point was that perhaps it's not best to store your .mpl plaintext alongside any .mla archives, if only because it (slightly) confuses the special relationship the directory might have to libname and the .mla files. Not a huge deal.

@bliengme You don't need to figure out the scaling factor like 100 yourself, to convert between units of similar dimension (eg, length).

Download unitsbasics.mw

@brian bovril You can utilize UseUnit to specify more than one mixed dimension in the same session. So you can call it several times, to force kWh/day as well as USD/day.

Download moreuseunit.mw

Could you please supply a simple (single, scalar) expression that illustrates your point?  Showing the expected result would also help.

Download inertsurdmaple2015.mw

@student_md Please do not post duplicates of this Question.

Please add the details of additional examples in this thread instead.

Please do not inline .pdf copies of papers for which you do not own the copyright. Use the link (URL) button in the editor instead.

I have previously sent you a message about this.

@mmcdara 

As Carl noted in the Post, "Maple's dsolve(..., numeric) allows symbolic input parameters for IVPs but not BVPs." For BVPs, separate calls to dsolve are needed to handle separate sets of parameter values. That may still leave the possibility of using Grid on separate dsolve BVP calls, depending on the goal.

(Slightly related to your comments on using dsolve with parameters for efficiency, in case you're interested: an old post about making animations of IVP solutions.)

@mmcdara If you're interested in details: Statistics is going through ExprectedValue to Moment. In Maple 2017.3 this worked:

c := (exp(1.2*t) - exp(.9*t))/t/.3:
coeftayl(c, t=0, 1);
                     1.050000000

But in Maple 2018.0 that fails.

c := (exp(1.2*t) - exp(.9*t))/t/.3:
coeftayl(c, t=0, 1);
Error, (in coeftayl) the expression does not have a taylor expansion at t = 0

That comes from calling normal on the derivative, and then failing in taking the limit.

c := (exp(1.2*t) - exp(.9*t))/t/.3:
cd := diff(c, t):
limit(cd, t=0);
                   1.050000000

cdn := normal(cd):
limit(cdn, t=0);
                 Float(undefined)

The issue with coeftayl could be fixed. But Statistics might even avoid that altogether by recognizing the special case.

The following example works in Maple 2017.3 (and back at least as far as Maple 16.02), but generates this error starting with Maple 2018.0 .

with(Statistics):
Q:=RandomVariable(Uniform(0.9, 1.2)):
Mean(1/2*Q);
Error, (in Statistics:-Mean) the expression does not have a taylor expansion at t = 0

There are several easy workarounds.

I've submitted a bug report.

@David1 The Optimization package in Maple is primarily a collection of local optimizers.

There is no numeric global optimization program in the world that "guarantees" a global optimum for any general nonconvex problem. (edit: That is a general issue of mathematical computing, and is not Maple-specific.)

But if you want to do numeric global optimization of multivariate nonconvex problems in Maple then your best bet might be the 3rd party downloadable DirectSearch package (v.2).  If your Maple version is at least 2018 then you could install its package directly from within Maple (via the login to the Maplecloud).

@Kitonum The OP didn't both to give the URL. I added it.

@itsme I have no idea what the Standard GUI is doing with interface options, other than what I can infer by experiment.

@Ahmed111 With the name d assigned the determinant of that Matrix, I just looked at the typeset 2D Math output of the following statement in my Maple 2018, and observed the common subexpressions I used for R1,..,R4.

simplify(simplify(collect(d,[rho,chi],u->simplify(u,size))),size);

And then I cut & pasted.

But if you are interested in common subexpressions, for the purpose of easier viewing or greater insight into the structure of your expression, then you might consider using an older output labelling mechanism. (I do not mean the equation labelling that one can see along the right edge of a worksheet. I mean an older mechanism, for prettyprint=1, that represents common subexpressions and makes output terse.)

For this current example it just so happens that the default "maximal label expression size" allows for automatic labelling of exactly the particular common subexpressions I used above (originally, by cut&paste) for R1 and R2. So below I happen to be able to construct that R1 and R2 programatically, which I find neat.

Download some_labelling.mw

I think that the automatic labelling of common subexpressions was one of the best features of the old Classic GUI. It's a great loss that the newer Standard Java GUI doesn't have it for typeset 2D Output and enabled by default (and with as clever an automatic mechanism as Classic had for deciding on the labels by size). The loss is made even more severe since one of the greatest instabilities remaining in the Standard GUI is in it locking up when trying to render very large expressions close to the default length-limit. There are a lot of examples where the common subexpression labelling mechanism can greatly reduce the total output display.