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 .

If you're going to use eval[recurse] then why not utilize the functionality to recurse, with,

   eval['recurse'](Pt[1],[Pt[2][],valsh[]])

instead of,

    eval['recurse'](eval['recurse'](Pt,valsh)[])

To address your observation: simplify(S1) and S2 differ as starting forms for simplification, and the starting form can make a significant difference to the heuristics of simplify.  You're asking for a "simpler" form, which is not the same as asking for some kind of canonical form.

By the way, there are a variety of metrics readily available, including length , MmaTranslator:-Mma:-LeafCount , `simplify/size/size` and even codegen:-cost .

My least favorite is length, not least because results can depends on choices of names(!). Switch a pair of names for each other and the measure can change.

Also, for fun, and all using Maple 2024.0,

simplify(combine(rationalize(simplify(S1))));
length(%);  # length 509

simplify(combine(rationalize(S2)));
length(%);  # length 467

Moving on, the following both get the same (even smaller) length.

simplify(combine(expand(radnormal(S2)))):
length(%);  # length 466

I beseeched my oracle, and the sybil whispered to me commands for an even more compact form,

collect(S2,[t],u->simplify(evala(u)));
length(%);   # length 398

note: You're measuring a list of two expressions. The size of the list accounts for both expressions. All these mentioned approaches are each applied to both expressions. So their individual sizes may play off each other in the goal of minimizing the total measure the the list containing both. You may well be able to find a separate approach for each, that makes the combined total size smaller still.

If you are going to pass multiple geometry objects to draw then they should be in a list. 

You made a similar mistake with textplot: the multiple lists of items need to be grouped within a parent list.

That's on top of all the errant `*` and/or bracketing issues.

Suggestions:
1) Stop using 2D Input since it's likely related to your recurrent problems with errant `*` and implicit mutiplication versus function calls.
2) Indent your code, with separate lines, so that you can more easily see the structure of long statements, nested calls, and syntax mistakes.
3) When you have problems with a long complicated display call, try each of its parts separately.
4) Read the text of error messages; sometimes they're confusing but often they give a hint
5) When having a problem with a specific command, read all of its Help page carefully.

Download JAMET_x.mw

One way is to replicate the plot, but with a singleton point (defined, and within range) and a lower thickness.

It's not perfect, but at least the legend entries are more distinguishable than in the original.

The limit at which it works on my system is thickness=2 .
 

Download legend_thick_hack.mw

It varies by example of course, but doesn't save much typing, say,

with(plots):
display(display(P,legend=""),
  plottools:-transform((x,y)->[Pi,0])(display(P,overrideoption,thickness=2)))

Here's a quick attempt at something flexible.

Download subs_recur_ac.mw

There are a few ways to finesse and improve it in terms of more involved functionality.

E.g. doing nested veiling using shortest first, and preserving "inner" results, instead of replacing longer-to-shorter.

Replacing instead by ascending length needs a careful cutoff, or else risks an unhelpful jumble of too many micro-substitutions, like from codegen:-optimize(eqn).