The answer seems to be due to the difference between applying eval versus limit for the IC.

This is apparently the same behaviour from odetest -- and certainly the same kind of example -- as in this older Question of yours from April 2024. And IIRC you posted another duplicate of that just the other week (though perhaps since deleted).

Download lim_eval.mw

@Andiguys This is to respond to your last Reply immediately above. I had a look at this last night, using Maple 2019 like you.

This seems to attain a minimum for TRC(sigma,nu,Q3).

N1_11_ac1.mw

Note that your ensuing plot3d call is confusing, since its first argument is an expression that does not contain I1 or I2. So it's unclear how you want to use any optimal values of sigma,nu,Q3. (I still don't think that you've made your full purpose clear, as previously mentioned.)

ps. I also tried to confirm the minimum using DirectSearch (from maple.cloud or the Application Center). For only Optimization:-Minimize I did some preliminary analysis to restrict the parameter ranges. The results seem to agree, though higher Digits was needed due I suppose to the difference in scale of Q3 versus sigma and mu.

Are you asking for a list of all the arguments to log calls in that input?

If so, note the additional ln terms introduced by Maple's evaluation of your input example. If you know that all your examples will be, say, polynomials of at least degree 1 in x then you might be able to get by with something like the first approach below. But more robust in general would be to use the inert %log when entering your input. (You described it as input.)

Download ln_indets.mw

There's no need to get into DataFrame complications here (eg. Tabulate of such renders row and column headers in 1D plaintext).

S5S4BoxPlotPondération_ac.mw

It's not entirely clear what you mean by "filtered" or "select". Do you want them returned in a new (smaller) DataFrame, or separated out from each other, or...?

Perhaps you want the result from,

    select(member,TestData,Case,SelectionList);

DataFrame_select_ex0.mw

I would prefer to transform a 2D version by transforming it onto the z=1 plane, instead of using intersectplot for a 3D version when it wasn't necessary.

display(transform((x,y)->[x,y,1])(plt1),
        scaling=constrained,caption="Projective Co-ords on plane z=1",
        axes=normal,axis[3]=[tickmarks=[1]]);

Having said that, I would also rather use a dedicated line-plotting command (line, or even plot with adaptive=false and numpoints=2) before I would call such a hammer as implicitplot for it.

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