The union command merges sets.

In this example, you don't need union at all. You can just use {C4, C44} .

If C3 and C4 were themselves sets, then you could use {C4} union {C44} (and which would also work here).

Download Q_Constraint_error_ac.mw

Here are two ways of doing it, each showing both the difference and the ratio, in side-by-side plots.

>  restart; with(plots): setoptions(size=[500,200],style=pointline,labels=[x,""]); First way, calling dsolve just once, and using a procedure to set the parameter value. Calling the dsolve-return at each x-value in the target Vector.   >  de := diff(f(x),x,x) = -sin(a*x): >  dsol:=dsolve({de,f(0)=1,D(f)(0)=1},numeric,parameters=[a],output=listprocedure): Y := eval(f(x),dsol): >  F := proc(aa::numeric) dsol(parameters=[aa]); Y~(A); end proc: >  A := Array([seq(0..3,0.1)],datatype=float[8]): >  display(Array([   plot(A, F(7.1)-F(7.0), title=y[7.1](x)-y[7.0](x)),   plot(A, F(7.1)/~F(7.0), title=y[7.1](x)/y[7.0](x), color="Navy") ]));   >  restart; with(plots): setoptions(size=[500,200],style=pointline,labels=[x,""]); Second way, calling dsolve for each parameter value, and specifying the output option to the target Array of x-points.   >  de := diff(f(x),x,x) = -sin(a*x): >  G := aa -> dsolve(eval({de,f(0)=1,D(f)(0)=1},':-a'=aa),numeric,output=A)[2,1][..,2]: >  A := Array([seq(0..3,0.1)],datatype=float[8]): >  display(Array([   plot(A, G(7.1)-G(7.0), title=y[7.1](x)-y[7.0](x)),   plot(A, G(7.1)/~G(7.0), title=y[7.1](x)/y[7.0](x), color="Navy") ]));

Download de_V.mw

There are even more ways of accomplishing this. I don't know whether you'd rather focus on simplicity, or flexibility, or performance.

If you omit the stated conditions that TM1,TM2,TM3 are all positive then the shaded regions extend to the boundaries of the Pn=0..1,w=0..1 square.

Download Plot_3D_to_2D_ac.mw

One of the important differences is that, while both a[1] and a__1 get printed/rendered with a subscript in 2D Output, the double-underscore a__1 name is wholly distinct and independent from a the base-name of a[1] the indexed name.

Yet there is a programmatic dependence of the name a[1] on the base name a.  In consequence, it is problematic to use both a[1] and bare a in a set of equations used with commands like solve, dsolve, etc.

It doesn't make much sense to form an equation or system of equations in which both a[1] and a are both present. Worse still, doing so can confuse the solvers and lead to wrong results.

But people often like having both the base name and some subscripted form appear in some 2D Math examples. For example, it's popular to use y(x) , diff(y(x),x), etc, as well as y__0 (with a subscripted rendering) as placeholder for the initial condition y(0). That's not sensible to do with y[0] instead of y__0.

nb. In Maple terminology, the name a__1 gets printed with a subscripted 2D Output form, but it is not an indexed name. The name a[1] is an indexed name. Both names get printed with a subscripted form.

Try executing the Document using !!! and, when the popup appears, add some expression (say, just x) and press OK so that the plot gets inserted.

And make "Markers" visible. By that I mean the left, thin, side-bar.

That execution may remedy the Markers which were previously muddled together.

Then you may see that the Marker for the problematic block has two parts, ie. the red line doesn't extend to its very top. On the upper, smaller part (without the red line, ie. just above the red line) you can try toggling the box from the right-click action,
   Document Block -> Show Command

Those steps revealed the inserted command, for me.

I think that using a procedure for handling M and Br values is more flexible than preforming a Matrix with a fixed spead of values for those variables.

The following is just one example of what you could do. Note that dsolve computation is only ever done once for any M,Br pair of values. Mere plot-data-transformations are all that's then needed once that computation is done.

There are several other ways to do it, including even faster approaches, or ones with the colors being  "blocked" instead of in a density-style of spread. I don't know what balance of simple vs flexible vs fast you'll want later.

Download 3D_shadow_at_the_base_Help_ac.mw

I think that it it helpful to have more direct visual cues as to which vertical axis pertains to each curve.

I like to do that with color, so, below, the curves are in various shades of the two vertical axes' base colors. (Another way is to use various symbols, with point style, and colors that match the axes.)

The result is that, mentally, one only has to associate rendered curve's color with the nearby axis colors. But in your original scheme one has to mentally go from the curve color to the legend, then know/recall that the legend name's subscript relates to one of the two vertical axis labels, and then find which is that label by reading. Relatively, IMO, that was considerably more effort.

Also, this lets us make a visual association between matching superscripts (ie, W,S, or D), since each pair of curves that share a superscript can also be made to share a common brightness (or point symbol). The two brightest curves are the "W" expressions, and the darkest are the "S" expressions.

I've used Maple 2019, as the OP does.

Download All_plots_Combined_ac.mw

Student:-Calculus1:-InversePlot is an appliable module.

That means that when you call it with arguments (as a function call) Maple actually invokes the following procedure,

   Student:-Calculus1:-InversePlot:-ModuleApply

You can get the nicely printed rendering of that entry-point with,

restart;
kernelopts(opaquemodules=false):
eval(Student:-Calculus1:-InversePlot:-ModuleApply);

Or you can get the line-numbered display with,

showstat(Student:-Calculus1:-InversePlot);

Note that in 2D Input mode (only) the input that looks like,

     mX(m, isumSD_TOT) := isumSD_REG;

may get parsed as code to construct an operator (procedure) of two parameters.

But you obviously want to do Matrix indexing, instead. And you have chosen to use the round brackets for Matrix indexing.

I can't tell which version of Maple you're using (because you didn't mark this Question with a specific version, and you haven't provided your actual worksheet). But you appear to have encountered a 2D Input syntax clash, and are not getting the interpretation that you want.

I was able to reproduce it a few times in Maple 2022.2. Not every time, but enough to confirm it can happen there.

So you could either use 1D plaintext Maple notation for the problematic input line, or you could use the square bracket notation for Matrix indexing, ie.,

   mX[m, isumSD_TOT] := isumSD_REG;

The documentation of the Help page with topic overload explains that the mechanism attempts the procedures in order, and that it proceeds to the next only if an error exception prefixed by "invalid input" were raised by the attempt.

Note also that such an exception is raised for a procedure only if the "missing" argument corresponds to a parameter that is actually referenced in the procedure. Note the following distinction:

Download proc_ref.mw

The above distinction is clearly documented (by explanation in first bullet point, and also by the examples) in the "Required Positional Parameters" section of the Help page with topic parameter_classes.

And now we can see that, if such a error exception were raised in your first example pair, then the overload mechanism would proceed to the next proc.

Download nm_overload_ex_ref.mw

Was the file already there? If it wasn't, then you've likely got the wrong location. It's the existing user GUI-preferences file that you're editing, and it should contain a lot of other GUI options stuff.

Also, is it named, say,
    "//Users/$USER/Library/Preferences/Maple/2025/Maple preferences"
with a number like 2025?

(It wouldn't hurt to also put your userid in, rather than $USER, though it ought to resolve in a shell. You might also do it with, ~/Library/Preferences/ ...)

Of course, if you already found right the existing file (with its contents) then the location aspect is not the issue. The edited line ought to start like the other lines, eg. no tab at left.

Also, did you fully quit all Maple GUI instances before both editing that file as well as relaunching?

It is correct.

That squared term comes from the expanding of,
    cos(2*k*x)
to,
    2*cos(k*x)^2 - 1

Note that Maple's expand command by default will expand as much as it can here. That includes not only expanding the form cos(A+B) but also resulting terms like cos(2*C) and sin(2*C).

Let's go through the whole thing, in a few separate steps.

Download trig_exp_ex.mw

It occurs to me that you might not have considered that replacement of cos(2*k*x) as a kind of expansion. (And apologies if you were already fully aware of this aspect.) You can take 2*k*x as being equivalent to k*x + k*x, and so consider it like expanding cos(k*x + k*x).

Yes, see number 2 example compared to number 1; A reportable weakness.

Download simplify_real_ex0.mw

ps. I don't like the approach of placing assumptions on all indets of type `+`; it's rather ad hoc, presuming that those are all real without stating them explicitly, etc. It's not stronger than this (weak, IMO) approach:

Download simplify_real_ex1.mw

Note the following, which does not need x>=0 to be a given assumption. Looking at the expression, it seems reasonable to me:

You need to be careful about which command it is to which you're passing the annotation option.

Here are a few alternatives.

Download plot_annotation.mw

@C_R It was an old (very old) design idea of Typesetting to have the mo (operator) and mi (identifier) be used to denote things intended to be pretty-printed in upright or italics, respectively.

But quite a short while after its original implementation (itself now over 20 years ago) some operators began being pretty-printed in upright, even if forcibly put into an "mi" construct. I recall asking about it (15+ years ago...) and not getting far.

You can see also similar treatment (done purely by the GUI, for rendering) of names sin, cos, ln, etc.

The rendering done by the GUI overrides/disregards the "mi", whether in the form,
   `#mi("sin");`
or,
    Typesetting:-mi(sin)

nb. You can force the output by using the function-call form, with options, eg.

    Typesetting:-mi("D",mathvariant="italic")

but the compact name-form doesn't support all such options (mathcolor being an exception). I suspect that this is similar to how right-click conversion to Atomic Identifier doesn't do the reverse action either, ie. it ignores italic characters interspersed in a name.