One way to accomplish that is to set the default unit(s) for which units of that same compound dimension will combine/simplify.

By default Maple's Units environments combine units to the SI standard. The SI standard unit for volume is m^3.

Maple's Units:-UseUnit command allows you to override the SI system, on a dimension-by-dimension basis.

For example,

Download UseUnit_ex.mw

Note that the above should only affect that particular dimension, eg. amount/volume. That can be distinct from the reciprocal of that dimension, of the square of it, or something with units of mol/m^4, etc.

In some scenarios you may need to call simplify ( or combine(...,units) ) in order to get the units in play to be merged. That can sometimes be true even without this custom use of UseUnit.

I used Maple 2022.1 for the computation above. If you have an earlier version that behaves differently then please tag your Question appropriately.

You can also programmatically convert units to compatible alternatives. That affects a particular result (though further computation with that might result in combining back to the SI standard). This doesn't require UseUnit. For example,

Download conv_unit_ex.mw

Yet another alternative (for the RHS of the above only, I suspect, and not that whole equation) is to use the relevant right-click context-menu item to change the display unit for a particular output.

Inside a procedure you can utilize the uses facility.

That allows the procedure to access the package exports without the need to have the package loaded at the higher level. (This can also be useful if you wish to store the procedure within a .mla Library archive, so that it can be subsequently used without the need to load the package. Ie, it can run stand-alone.)

As a toy example,

Download uses_example.mw

Some people prefer an alternative, in which the uses facility is utilized to provide a terser way to access the exports, like an abbreviation. This still allows more compact coding, but adds some legibility so that you can more easily recognize what's happening later on.

Download uses_example2.mw

Imagine a scenaro like, say,
   uses Cal=Student:-Calculus1;
so that you could have code with calls like Cal:-Roots(...) which is still reasonably terse but also understandable.

In your first example, that use of Physics:-diff causes an assignment to a remember table for top-level :-diff, which can be removed using forget.

Download diff_forget.mw

(This can also be seen by examing op(4,...) of the :-diff procedure after that Physics:-diff call is made.

The second example seems more involved, and I haven't yet figured it out. It may be related to the Physics package calls within the Library routine `simpl/conjugate`.

I am unsure of the root cause of the discrepancy. You could resolve that particular inconsistency with,

   int(..., numeric, method=_Dexp)

or,

   evalf(Int(..., method=_Dexp))

Also, your integrands may be complex-valued due to floating-point (ie. approximate) coefficients along with the presence of I, the imaginary unit.

You may get rid of small floating-point imaginary artefacts in results by wrapping the results in call to fnormal.

You may get rid of 0.0*I imaginary components of a result by wrapping in a call like simplify(...,':-zero').

Eg,
   simplify( fnormal( evalf(Int(..., method=_Dexp) ), ':-zero');

I don't understand why you apply evalf to the integrands passed to the quadrature call.

Btw, while you might be deliberately trying numeric quadrature for speed (say), much of your results can be obtained using exact symbolic computations (including erf calls in results) if you use exact rationals instead of floating-point values for your parameters, etc. In at least one way that can also symbolically show that the imaginary part of your integral is exactly zero.

The following is not real-valued for purely real x. But it's not awful.

Download intfun1.mw

I don't know how to get it as H or F in the Comments on the Question, which are real-valued for real x.

I'm not sure exactly how the names you used figure in the process.

But perhaps something like the following can be turned to your purpose.

Download memoi.mw

Here is one way:

Download some_set_stuff.mw

If you really want you could devise an overloaded scheme where those names union, minus, and intersection act similarly (say, by performing the operations such as I showed, underneath).

You may pass the option explicit (or explicit=true) to the solve command and obtain the explicit roots of a 4th degree polynomial directly, with a single command.

For your example, say,

    solve(Opt_effort_FOC = 0, e[n], explicit)

Inside the procedure p2 you need to use the global name :-debug as the name of the keyword option when it calls procedure p1.

p1 := proc(a, b, {debug::truefalse := false})
   print("p1", debug);
   a + b;
end proc:

p2 := proc(a, b, {debug::truefalse := false})
   print("p2", debug);
   p1(a, b, ':-debug' = true);
end proc:

p2(1, 2, 'debug' = true);

              "p2", true
              "p1", true
                  3

Otherwise your p2 is calling p1 with true=true, since inside p2
    debug = true
evaluates using the value of the p2 parameter that is also named debug.

Here is what's happening in your original. Notice the arguments that p2 passes to p1 include
   true = true
and not
   debug=true
which was what you'd expected.

restart;

p1 := proc(a, b, {debug::truefalse := false})
   print("p1", debug);
   a + b;
end proc:

p2 := proc(a, b, {debug::truefalse := false})
   print("p2", debug);
   p1(a, b, debug = true);
end proc:

trace(p1):
trace(p2):

p2(1, 2, 'debug' = true);
{--> enter p2, args = 1, 2, debug = true
                           "p2", true

{--> enter p1, args = 1, 2, true = true
                          "p1", false

                               3

<-- exit p1 (now in p2) = 3}
                               3

<-- exit p2 (now at top level) = 3}
                               3

Now observe what happens in the corrected version. Notice what arguments p2 passed to p1.

restart;

p1 := proc(a, b, {debug::truefalse := false})
   print("p1", debug);
   a + b;
end proc:

p2 := proc(a, b, {debug::truefalse := false})
   print("p2", debug);
   p1(a, b, ':-debug' = true);
end proc:

trace(p1):
trace(p2):

p2(1, 2, 'debug' = true);
{--> enter p2, args = 1, 2, debug = true
                           "p2", true

{--> enter p1, args = 1, 2, debug = true
                           "p1", true

                               3

<-- exit p1 (now in p2) = 3}
                               3

<-- exit p2 (now at top level) = 3}
                               3

By the way, I wrote as ':-debug' = true so that it would work even if the global name :-debug had also been assigned a value (at the top-level, say). Strictly speaking I didn't have to do that, since :-debug is a protected name. But for the same situation involving other (unprotected) names you could have that situation. So I wanted to illustrate to you the more robust way.

[note: See here for details I gave in your earlier Question thread, for plotting the 0-contour using interpolation of 0-height data that is computed more robustly. That seems to make this Question thread less relevant...]

You appear to be using Maple 2021, so you can use the newer Interpolation package (new in Maple 2018), which makes the task of interpolation "on-the-fly" easier.

The black-box that it returns can be subsequently polled at arbitrary x-y pairs, so you can easily use it with the contourplot command.

The problem is that you original data is quite flat for higher y-values, and the data you generated for it seems to lack enough precision to allow the 0-contour to be traced out nicely. (I alluded to this in your earlier Question thread, since I had already tried what I show below...)

In the plot below you can see that it has difficulty following the 0-contour, and slight inaccuracy in the original data can cause it to veer off the (exact) course.

Using ArrayInterpolation would not fix this issue, in and of itself. That command merely provides a mechanism to compute all the interpolated x-y target points in batch. I suspect that a good fix would require greater accuracy in the originally generated data -- which would be slower, and you earlier asked for it to be faster. It's possible that a scaling of the data to give it greater slope might be a kludge. But since the curve represents a function (in the mathematical sense) then it be more robustly found using fsolve (to find the alpha corresponding to each beta); again, see here.

Download test1_interp_acc.mw

It's not very helpful to split these detail and highly related queries across multiple Question threads. At this time the .xlsx data file is at attachment in your earlier thread, but not in this one. And the quantitative nature of that data bears on which are decent courses of action.

Please try to keep your related queries in the same thread, even if nobody yet answers all to your satisfaction.

There is a special substructure of a 2D plot which the GUI recognizes as instructions for filling a popup box when the mouse-pointer's focus lies over that particular plot feature.

You can build that into your individual plot features (curves, points,...) by using the annotation option.

See the Help page for Topic plot,annotation .

Download Q_9-9-22_limit_in_integral_ac.mw

The names generated by solve come in only a few flavours, so you might be able to get by without need for consideration of the names in the original expression f. For example,

restart;
assume(M::nonnegative):
f := 10*cos((-1+t)/sqrt(1+M))-10*cos(t/sqrt(1+M)):
g := solve({diff(f, t), t>0 }, t, allsolutions)[1][1]:

indets(rhs(g),And(name,Not(constant),
                  ':-suffixed(:-_)'));

           {_Z2}

indets(rhs(g),And(name,Not(constant),
                  ':-suffixed({:-_B,:-N,:-_Z})'));

           {_Z2}

I don't see a natural reason to attempt a heavy handed approach like as follows. (The original expression might have already had such generated names, in which case a combined approach might be needed.)

convert(indets(f,And(name,Not(constant))),`global`):
convert(indets(rhs(g),And(name,Not(constant))),`global`) minus %;

           {_Z2}

Simpler results can be had in Maple 2022.1, using the method below.

Perhaps someone can come up with something more direct. I programmatically determine the second root, to be less ad hoc about passing a range to Calculus1:-Roots.

The Calculus1:-Roots and maximize commands have a special (peppering) technique for determining values of the _Zxx assumed-integer parameter that solve returns here when passed its allsolutions option.

The solve command has improved in the past few releases, as far as returning a finite number of explicit roots when passed inequalities that denote a finite range. But it still seems not generally as strong as that internal technique of Roots and maximize. For this example solve returns a general formula when supplied its allsolutions option, but seems to return NULL when instead passed various reasonable inequalities, e.g t>0,t<10.

Here it is first with Maple 2015.2,

Download ToyProblem_ac2015.2.mw

And here that is in Maple 2022.1,

Download ToyProblem_ac2022.1.mw

Is this the kind of thing you were trying to accomplish?

I wasn't sure whether you wanted only the floating-point approximate root where f(n)=g(n), or an exact result for that, or the next highest integer above that where f(n)>g(n).

Download ex1.mw

An exact result is also possible, in terms of the LambertW special-function.

solve({f(n)=g(n),n>5},n):

    { n = -8/ln(2)*LambertW(-1,-1/8*ln(2)) }

evalf(%);

   {n = 43.55926044}

Your Question shows an unevaluated call to intervalsolve, as a returned value. There is no such command in stock Maple. There is such a command in the Gym package (used by Danish schools). If using that command was your intention then you made two mistakes:

1) Your unevaluated return value shows that you failed to refer to its name properly. You could either use the command's fully qualified name (by including its package name in the call), or you could first load the package and then use the command's short name. See below, for examples of both.

2) The calling sequences of arguments that you passed is also incorrect for that Gym package's command. See below.

Here below is that command working in Maple 2021.2, called in a few alternate ways.

(These produce the same results in Maple 2022.1 and Maple 2020.2. You didn't tag your Question with your Maple version number; that can be useful information for us if it's an old version.)

Download intervalsolve_Gym.mw