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.

@itsme Thanks.

I suppose one might also replace the conjugate(K3)+K3 by 2*Re(K3) , but maybe we're already in territory where beauty is in the eye of the beholder.

@vv Yes, I was wondering whether a fortuitous Change and Split might allow resolution of the `abs`, which might make it more tractable.

@mschneider Let me know if this handles at least some of your other problematic examples.

Download parsedelay.mw

@digerdiga The Cuhre method of the Cuba library (an external link to which evalf/Int calls) is documented as being a deterministic and not a Monte Carlo approach. It implements a globally adaptive subdivision scheme.

@tomleslie DirectSearch:-SolveEquations has its own depressing bugs and faults.

@Christopher2222 Then why did you name this Post as "Maple 2019 wishlist"??