It's clearly a weakness that simplify(e1,trig) does not gets the compact sec form, while the following does,
   simplify(tan(x+c__1)^2+1,trig);   # returns sec(x+c__1)^2
 

Download tan_sec_simplification_june_9_2024_ac.mw

Note: this is not the first time that you've mentioned that you expected simplify(...,size) to get some particular form that required a mathematical transformation outside of that option's documented functionality. See the first bullet point of the Description section of the ?simplify,size Help-page.

Check whether this is the minimization you intended.

Download Updated_model_ac.mw

Your updated model attempt had several mistakes (syntax, spelling, etc).

Here is what I get,

Download why_print_empty_june_7_2024_ac.mw

I am running with this setting:

   interface(typesetting);    # standard

That is the default for a wholly fresh installation of Maple 2024.0 on Linux (with no older preferences imported).

That corresponds to the GUI Tools->Options->Display setting,
    Typesetting level   :   Extended
whereas you show that above as being,
    Typesetting level   :   Maple Standard

If I changed the interface setting (by interface command or by GUI Options menu) from extended to standard then I do get a blank output for the relevant line.

When that happens, I also get some Java error messages in the shell from which I launched the GUI. The beginning of that indicates that it has run amok of the Matrix with a dimension being zero.

While there were GUI changes for Maple 2024.0 related to the new Scrollable Matrices feature, I was unable to work around it for your example by disabling the effect of that new GUI feature. However I don't see the issue in my Maple 2023.2.

Here is one way, which shows it as 2D Math.

You can also put unassigned parameter names into a InertForms:-Display call, and then substitute numeric values for those (using `eval`, or `subs`) after computing such.

Download inertform_textplot.mw

You could instead use,

   patmatch(stat,`^`(0,a::anything))

This is to avoid your  0^(a::anything) becoming zero during your call.

Download nm_zero_power_proc.mw

For your original, I see these arguments being passed to patmatch. Note that the second  argument received is just 0.

Download nm_zero_power_orig.mw

With the prefix form given above, trace shows that patmatch receives,
    0^n, 0^a::anything

There appear to be some inconsistencies (not affecting your given example, however) which I'll report.
hm_zero_power.mw

Here's one way.

Download nm_simp_exp0.mw

The sort call is there only because, depending on what's gone on earlier in the session, the subexpresssion in the final result can appear as,
      -1 + 2*exp(-2*x + 2)
instead of,
       2*exp(-2*x + 2) - 1
and you may have an aesthetic preference. This happens for me if I merely define e2 as you have it, before proceeding.

I presume you have some way to elect whether you accept this or not for other examples where it doesn't improve things.

Your given example can be handled by either of the following two ways,

C:={a=1/sqrt(2+A),b=6*sqrt(4+N) ,c=sqrt(7),d=5*H,e=-12,f=-96}:

selectremove(u->not type(rhs(u),constant), C);

   {a = 1/(2+A)^(1/2), b = 6*(4+N)^(1/2), d = 5*H},
   {c = 7^(1/2), e = -12, f = -96}

selectremove(u->indets(rhs(u),name)<>{}, C);

   {a = 1/(2+A)^(1/2), b = 6*(4+N)^(1/2), d = 5*H},
   {c = 7^(1/2), e = -12, f = -96

That first way can also be entered with a terser syntax for the type-check,

    selectremove(u->not rhs(u)::constant, C);

And if you just need the first of that returned pair of sets,

    remove(u->rhs(u)::constant, C);

For that second way (in the gray box) I just used a custom operator as the first argument, in a two argument call to selectremove. The first argument doesn't need to be the name of some stock command, and you don't always need to pass in extra aguments to it.

However, for that second way, in general you might want to guard against some special cases, and be more picky about which kinds of name matter.

For example, Pi is of type name but you might want to exclude it from the names that matter.

And if you have Int(4,t=0..1) and that name t acting as the variable of integration doesn't appear anywhere else then you might not want it to count. (I know, it's a contrived example.) The point is that you might want to consider only names upon which the rhs depends.

These aspects might not matter to you here, but in practice they crop up quite often when trying to extract variable names from expressions. 

Download 2024-06-05_Q_Select_Remove_indet_elements_ac.mw

note: You might well find shorter syntax. Look for code that you could understand later on your own (provided it's reasonably efficient), over code that is less natural to you (no matter how terse).

You could try using

    max( lowvalue, min( maxvalue,  expr ) )

around the expression, and then using,

   view = [ lowvalue+eps .. maxvalue+eps ]

for some relatively small eps.

Those view particulars prevent any extra flat portions induced by this approach from appearing. But the max/min allow the colorscheme to use your specified boundaries for the extremes of the zgradient. Hence the color gradient is created and applied only for the targeted range.

An alternative is to use valuesplit instead of zgradient in the colorscheme. That allows to you to target your desired shading for just a range that matches your specified view. (Ie. you write the splitting values to make them match.) This seems to be the approach that you mentioned avoiding.

I prefer the first method because sometimes when there is a huge variation the GUI has weird flashing as the 3d plot is manually rotated. Getting rid of the huge (pos/neg) extremes fixes that for me. Also, the max/min approach can work better with a colorbar. It gets rid of the extreme values altogether. The valuesplit is not so helpful for these aspects.

You'd normally need an inert representation in some way, or else the result will evaluate right back to your complex number.

For example, (sorry, the site's not rendering the worksheet quite properly),

Download inert_exp.mw

The Kr value is the subscript, in the legend items.

This uses the same color for a given Kr value, and the same linestyle for a given function (from f,Theta,Phi).

animation_of_ode_ac.mw

For your second example, here is one way,

Download nm_simp_exh.mw
 

Also, for x>0,

Of course, there may well be shorter alternatives.

You have,

   xM2 = rhs(sol2[1]);
   yM2 = rhs(sol2[2]);
   xM3 = rhs(sol3[1]);
   yM3 = rhs(sol3[2]);

which are not assignments. Those are just equations.

Change = to := and it works.

You don't need the assume call.

JAMET_2.mw

I've deliberately done this in stages, for a little more clarity.

The idea is to replace a subexpression of the form Int(Sum(...)) with Sum(Int(...)), i.e. bring the integration inside the sum.

Download 1111_ac.mw

@Dkunb You could examine the results from, say,

   collect(combine(convert(eq13,trig)),[sin,cos],simplify)

which could also be done with, say, assuming n::even,m::odd etc.

In such a case I don't know whether you'd prefer the collecting of terms by real/imaginary (ie. factor of I) or by sin/cos arguments, or by denominator factors.

The command log (with no index supplied, ie. no base specified) is the same in Maple as the command ln, i.e. the logarithm with respect to the default base e=exp(1), ie. the natural logarithm.

log(0.5/1.65)
                          -1.193922469

ln(0.5/1.65)
                          -1.193922469

log[exp(1)](0.5/1.65)
                          -1.193922469

log10(0.5/1.65)
                         -0.5185139399

log[10](0.5/1.65)
                         -0.5185139399

See also the second paragraph here.

This is also described on the Maple Help-page viewed by executing  ?log .