Try closing the context-panel, by which I mean the right-hand window in which context menu operations appear.

The problem may be the so-called smart-popup operations (a plot, etc) that appear at the top of that right-hand panel.

You have `u` as an expression in `y`, but then you call it like u(y) inside diff(u(y),y) as if it were an operator.

That's a mismatch.

Either differentiate like diff(u,y) or make `u` an operator/procedure of one parameter, eg. u:=u->expression_in_y .

But don't change both, or they'll still be mismatched.

Here is one way, a short edit from your code,

restart;

expr := exp(x)^3*sin(x)+3/(exp(x)^n):

subsindets(expr,'exp(anything)^anything',
           f->combine(f,exp,symbolic)):

       exp(3*x)*sin(x)+3/exp(x*n)

By the way, the "problem" was not that the exp call was in the denominator. The difference was the name n as outer power.

Download exp_comb.mw

[edit] I am supposing that you know that the identity is not true for all complex values of the parameters. However you might have had the following in mind,

subsindets(expr,'exp(anything)^anything',
           f->combine(f,exp)) assuming x::real;

       exp(x*n)*sin(x)+3/exp(x*n)

The location of the preferences file is platform specific, and you haven't mentioned your platform.

You can set the preference for input mode in the main menu, from item,
   Tools->Options->Display
and toggle the combo-box "Input Display" to "Maple Notation".

You can set the default for new sheets to Worksheet  in the main menu, from item,
   Tools->Options->Interface
and toggle the combo-box "Default format for new worksheets" to "Worksheet".

If you then click the "Apply Globally" button in the preferences popup then it should write out and save those values in the preferences file.

Download help_fsolve_real_root_acc.mw

Perhaps the question is asking for something like the following (where the flow units will be in m^3/s).

(If you are being asked a homework question on the trapezoidal and midpoint methods then will you not have covered those in lectures?)

Download trmdpt.mw

It seems that you have avoided reading the Maple help pages for LinearAlgebra.

(check for mistakes)

Download lahw.mw

There is no such command, RTABLE.

The name RTABLE is a protected name, and is utilized as an inert function call for printing purposes. For example, the procedure `print/rtable` uses such calls for formatting, in a way that the GUI understands and deals with. Printing rtables (Matrix,Array,Vector) has some special situations.

This is undocumented, and I am hard pressed to imagine a good reason why anyone would want to display using such calls. Your remarks about "messing up the order of things like sums" is pretty opaque.

Relying on undocumented behavior for complicated, customized display effects is a bad idea.

I am wary of the methodology that the local proc may return expressions with an unknown number or escaped locals -- possibly without pattern in their naming, but it's difficult to judge without knowing full details. On the surface it sounds like a programming mistake. I would prefer to utilize `tools/genglobal` to produce a new unassigned global name safely than to escape a local (which is poor practice).

In examples such as for your new edit, with alpha as the dummy variable of integration, assumptions during subsequent computation would more usually be placed on x the name appearing in the limit of integration.

Your question is not about simplify (or even assuming) per se. It is about programmatic access to (and use of) the names appearing in the expression returned from the procedure. It is about handling escaped locals programmatically -- or, IMO, whether it would better practice to use a better approach that does not return escaped locals.

Download deps.mw

You can easily programmatically generate conditions from the dependent (or independent) variable names, and use those in a call to simplify (or other command) under `assuming`. That's generally quite straightforward, once you have lists of such names with which to further program.

I will repeat that I think it is poor practice to return escaped locals from a procedure. The fact that they are subsequently awkward to deal with programmatically is just one reason that it's poor. Instead, I suggest passing in a global name of your own choice or generating new (safely non-assigned) global names using `tools/genglobal` and a base name of your own choice. I realize that `tools/genglobal` is undocumented, but its usage it simple. It exists because it is used by Library routines quite a bit. It serves a rather frequently occurring programmatic purpose. I used it as a key part of an Answer to your Question of 07/07/2020 and another Question of 19/09/2020, both of which have similarities in vein to this thread.

Here is something, numerically,

Download cuba_surfint.mw

Here is one way to generate it as a list of column Vectors. (I haven't looked at whether it is an efficient way, or whether it scales up well, etc. I suspect that it may be wasteful in terms of producing unnecessary collectible garbage.)

Also, do you really need all of them at once (like this), rather than comptuing with them one at a time?

Download vecsplode.mw

Download funintegral.mw

vv mentioned doing it by hand. The only heavy lifting in the above is in the evaluation of the integral (inside the sum) following the call to Change. One could recognize a GAMMA call for that -- followed by cancellation of the factorial terms.

Try specifying the labels with the option as,

  labels = [:-D[m1], c]

or,

  labels = [`#msub(mi("D"),mi("m1"))`, c]

or (if you prefer the font in upright Roman),

  labels = [`#msub(mtext("D"),mtext("m1"))`, c]

labels_glob.mw

You can specify a predicate which does a table lookup on the entries.

Using a key (to specify the quality to compare) should be more efficient, which could matter if you have many items to sort.

Listsort_ac.mw

You get the comparison of strings automatically. Hence the only thing you needed to add is supplying a comparison that did the table lookup of the quality by which you wished to sort.

evalb("Concrete" < "Timber");

                true

materiallist[1]["material"], materiallist[2]["material"];

           "Timber", "Steel"

evalb(materiallist[1]["material"] < materiallist[2]["material"]);

               false

Have a look at these references, which mention difficulties for the floating-point computation:

  wikipedia

  Matlab help

The first of those also points at the Schur decomposition (see also SchurForm in Maple).