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).

Does it help if you do it something like,

   barcaption = "Counts\n\n\n"

One thing that ODEsteps cares about is whether there is a derivative present.

It should be possible to construct a wrapper that splits the equation (factors, say) according to whether there is or is not a dependence upon a derivative (ie. an "ODE").

Purely as an example,

Download odesteps_hack2.mw

Please don't tell what it doesn't succeed at. This was a 5-minute piece of programming purely for illustration. That frontend'd solve call is blind to lots of forms, and selective freezing might well be much better. It's obviously neither complete nor robust. I even hard-coded it just for y(x).

I know that the OP already has his own ODE solver(s), so I wouldn't be surprised if he already had his own mechanisms to split in similar manners (ie. using ODE techniques for just the parts where derivatives came into it...).

During tracing "unknown" refers to an anonymous procedure.

Here, "anonymous" means that the procedure or operator is constructed without ever being assigned to any name. See subsection 6.9 of the Programming Guide.

That aspect displaying as "unknown" is described in its own subsection of the Description on the Help page of the trace command.

There are various ways to apply an anonymous procedure. For example, using printlevel as you have,

Download unknown_unapply.mw

Another common example is something like the applications of the first argument to map below,

     map(t->t^5,[x]);