You could use the inert form %log[b] . You might also use InertForm:-Display(..,inert=false) to get that rendered in black (instead of gray).

DisplayLogQCM_ac.mw

How about specifiying the types on the (procedural) parameters in the preliminary call to codegen[makeproc]?

Eg, (notice the parameter specifications of the procedure),

   codegen[makeproc](TheList, parameters = map(`::`, [proc_params], float[8]))

Those were specified programmatically, not manually.

Download C_code_generation_with_CodeGeneration_ac.mw

Your current problem is due to the fact that your collatz procedure is returning NULL.

That is, calls like collatz(13) have a return value of NULL. That happens because the last line of your collatz procedure merely prints max_i. The print command itself returns NULL.

Try it with the very last line of collatz being,

   return max_i;

after (or instead of),

   print(max_i);

Here's one simple way,

   m:=Matrix([[1,2,5,6,9],[3,4,5,13,14],[1,3,4,10,11]]):
   dataplot(m^%T, style=line, gridlines=true, size=[500,"golden"]);

The size option is optional. (That instance of "golden" refers to the aspect ratio; I could have used approximately 0.618 instead.)

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 .