Here is one way,

Download PMSM_eq_ac.mw

[edit] The following is shorter (only because it avoids having to dispel the constant of integration), but it seems slightly odd (to me) to ignore the dsolve command entirely.

IntegrationTools:-Combine(solve(value(map(int,PMSM_v_eq,t)),
                                {lambda__alphabeta(t)})[]);

It's not clear from your question how you want to treat multiple (or nested) solutions coming out of solve, as your only example is simple. I could guess...

Download solve_removal.mw

@coopersj The default behaviour of the 2D Input  ||V||  should match the current context's behaviour of Norm(V) , in the case where neither explicitly specifies a particular norm.

Of course, each should always be available -- if provided explicitly -- so as to clarify the situation if the nature of the worksheet's material and content make the context non-obvious. And so they are. I used command-completion on the word "Norm" whilst in 2D Input mode, to select a specified norm from the popup menu.

Download norm_LAVC.mw

One way to get the results without the x is to change how you call fsolve, ie.,

f := x^2-x+0.25:

fsolve({f=0}, x=0..1);

     {x = 0.5000000000}, {x = 0.5000000000}

[fsolve(f=0, x=0..1)];                          

         [0.5000000000, 0.5000000000]

Your first question about "storing" the results is unclear. If you assign the last result about to S then you can access each root by indexing, eg,

S := [fsolve(f=0, x=0..1)];

          S := [0.5000000000, 0.5000000000]

S[1];

                  0.5000000000

S[2];

                  0.5000000000

Under the location of my Linux installation of Maple 2020.1 there is a file (relative path):
   bin/Maple2020.png

That is a 1-layer 48x48 pixel RGB color space PNG image, at 72x72 ppi and a print size of 16.93x16.93 mm.

You could try scaling that up in size (after making a copy of the original file).

Of course, the final behavior is up to your twm window manager.

The simplest way to switch the orientation roles is to use the parametric calling sequence of the plot command.

plot([y^2, y, y = -3 .. 3],
     color=blue, thickness=3, title="T1.1 x=y^2 [ECE]",
     view=[-5..5, -5..5]);

I don't care so much for the three choices Tom mentioned. The rotate example involves more typing, a little extra computing, generates a temporary plot as collectible garbage, but is otherwise ok. Solving/inverting the expression analytically for all branches is problematic in general. And implicitplot is inefficient (compared to a direct plot).

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.