The effect you're seeing is the effect of uniquification by the Maple kernel. It's not just about the display of the expression; it's about how Maple stores its unique structural representation in memory.

The effect you're seeing is the fundamental storing and unique representation that the Maple kernel does for the  Directed Acyclic Graph (DAG) representations of expressions it has a session. It stores the DAGs in a hashed data structure. That structure is sometimes called the "simpl" table.

Yes, this is to ensure that all equivalent expressions are stored only once in memory. But it is not a table in the usual sense for the Maple language, and there is no general purpose, direct access mechanism to it for the user.

It is not a "remember table", which is a feature of PROC DAGs. Those are accessible as a table. It is not that. There is no remember table to forget.

The sort command allows for some in-place replacement of the representation of an object in that internal "simpl" table. If the unique representation is changed, then it appears changed anywhere else where that very same DAG is accessed/pointed-to, or in any new created DAG that contains it. But the sort command only allows one to sort with respect to certain kinds of expression.

If your use of eval returns an expression whose DAG contains an already existing/simpl'd DAG then the new instance of the (sub)expression will be the same as what was already simpl'd.

Some examples,

Download sort_fun_2.mw

Download sort_fun_3.mw

Download nm_ode_ex1.mw

You could try the option,

    obsrange=false

Is there a reason that you don't use plots:-odeplot instead, or allow for any adjustments to control the error?

The enlargement of the y-range that allows this particular example to work as you expected (without obsrange=false) seems much smaller than 10% which you used.

Also, you haven't supplied an example in which you need the y-range. You've claimed that you sometimes run into issue without it, but haven't provided examples.

ps. Is there a specific reason for all that `op` and `originalview` stuff, as opposed to, say, using plottools:-getdata with its rangesonly option?

Some years ago the so-called "typesetting rule" for some special functions (like the Bessel family) was changed from true to false by default.

That Help page you've cited appears to not have been updated accordingly.

But you can still enable it using:

  Typesetting:-EnableTypesetRule("BesselJ")

(or, I suspect, by using the RuleAssistant dialog from that same package).

Download Typeset_ac.mw

Those errors all occur in Maple 2024.2

But in Maple 2023.2.1 they get solved (and they solutions satisfy the equations).

Here's another shot at the integral, with a check, if we consider tau to be real-valued.

The result is attained in that first line of computation.

The result prints reasonably nicer in the actual Maple GUI, and computation is overall reasonably quick.

Download nm_int.mw

There are some variants, trading off, say, continuity at (some) points versus compactness, according to piecewise constants for the three regions obtainable by splits at tau=-1 and tau=1.

The reason you didn't see the effect on your plot3d result is that none of the input points has alpha in that same problematic range as has your plot result.

Your plot3d result has a range of 0..15 for alpha. And the default grid size is 49x49. However, none of these 49 generated values for alpha in that special range just below 0.1.

seq(0 .. 15.0, numelems = 49);

   0, 0.3125000000, 0.6250000000, 0.9375000000, 1.250000000, 
     1.562500000, 1.875000000, 2.187500000, 2.500000000, 
     2.812500000, 3.125000000, 3.437500000, 3.750000000, 
     4.062500000, 4.375000000, 4.687500000, 5.000000000, 
     5.312500000, 5.625000000, 5.937500000, 6.250000000, 
     6.562500000, 6.875000000, 7.187500000, 7.500000000, 
     7.812500000, 8.125000000, 8.437500000, 8.750000000, 
     9.062500000, 9.375000000, 9.687500000, 10.00000000, 
     10.31250000, 10.62500000, 10.93750000, 11.25000000, 
     11.56250000, 11.87500000, 12.18750000, 12.50000000, 
     12.81250000, 13.12500000, 13.43750000, 13.75000000, 
     14.06250000, 14.37500000, 14.68750000, 15.00000000

Note that your RootOf expression contains no information that would indicate to fsolve (which is called by `evalf/RootOf`) which root is desired, or what range to compute over or take initial values from, etc.

But you could add a range descriptor to the RootOf. In this example it happens that we can figure out that the roots are either negative or positive, for your range of alpha. So that helps.

Note that in your original example fsolve gets called (for each numeric alpha value) without any specified range. But in the edit below it gets called with the range 0.0..infinity, and only the positive roots get found.

Download plot_of_RootOf_ac.mw

You can verify my explanation by setting trace(fsolve) and then calling it like the following (for your original RootOf without range descriptor, and also for my edit that has it),
    plot(a, alpha=0..0.5, adaptive=false, numpoints=7)

And you can verify my comments about plot3d in a variety of ways (including specifying the very same alpha range, or increasing the grid, etc).

Here attached are a few approaches. But first a few notes:

I don't yet see a nice+easy+sensible+robust way to "simplify" more general things like,
    2 - cos(x)^2 - cos(y)^2
into,
    sin(x)^2 + sin(y)^2
without also clobbering standalone terms like cos(v)^2 into becoming 1-sin(v)^2 undesirably.

Part of that relates to the fact that simplify doesn't use directly measured expression size and comparison as its main/only aspect for all mathematical simplification (trig, radicals, etc). The purer size compression & comparison focus is more for arithmetic/polynomial restructuring (ie, `simplfy/size` which it now does as a finishing/polishing step).

I wonder whether the procedure K below might be more generally useful to the OP than the other approaches attached. That just allows simplify to do its thing, then patches up that csgn split, after-the-fact.

So, fwiw,

Download simp_trig_ex9.mw

In the Maple 2025 ribbon, choose,

    Edit -> Editing -> User Profile

and in the pop-up dialog that appears choose "Engineering Notation" from the drop-menu.

Then close that with Apply And Set As Default

After that, in newly opened sheets you should get it by default.

There are several approaches that won't work, and some that will.

Which you choose might depend on whatever else your code might do.

Download max_units.mw

As the error message indicates, the intersection command expects the first argument to be a name.

Note that the passed name H gets assigned a value, during the first call to intersection.

Then, in your problematic second attempt, intersection receives the value assigned to H rather than the unevaluated name H. That's due to Maple's usual rules for up-front evaluation of arguments passed to procedure calls

You could instead pass 'H', within unevaluation quotes (ie. single right-ticks), if you want to re-use that name.

Download Test_intersection_ac.mw

The result from detail don't print properly when the worksheet is inlined on this forum, but in the actual Maple GUI the updated data is shown.

This technique of quoting a name -- to protect it from unwanted evaluation -- also arises for other commands that act on a supplied name with the side-effect of assigning some value. For example,

Download side_effect.mw

Here is a Maple sheet that illustrates a pitfall, and a couple of alternatives.

Let us know if aspects are still unclear.
 

Download solve_asn_rec.mw

ps. At the risk of partly repeating myself...
    M[8] := eval(M[8], raw);        # OK
    M[8] := rhs(raw[1]));             # poor

[edit]
Maple guards against a recursive assignment, as shown above. If you trick/force it, and then evaluate, you can see a similar error message to what you had from Maple Flow. I mention this just to illustrate the similarity. Eg,

Is this the kind of thing you're after, for the,
   MinMachineNumber
   MaxMachineNumber

Download evalhf_const.mw

See the ?evalhf,constant Help page.

And for the "software" float case, you could look at the ?Maple_floats Help page. (But MAX_FLOAT divided by MIN_FLOAT would produce Float(infinity) in that context... as would DBL_MAX/DBL_MIN under evalhf.)

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.