The plot shows that the local maximum is the global maximum over that range t=0..2.

So you can use the Optimization:-Maximize command.

In my opinion this is more straightforward, flexible, and likely more accurate in general than either examining the discrete data points from a plot structure, or using an interpolated spline.

I use the output=listprocedure option for dsolve, as a convenient way to get at procedures for xn(t) and zn(t), similarly to what I showed in your previous Question.

Download evalv_max_ac.mw

There's nothing intrinsically wrong with returning NULL as an explicit statement. This is a common programming technique in Maple.

   return NULL;

One alternative is to have a statement that does nothing and happens to also return NULL, but that would be obfuscation for no benefit. The explicit return call is clear and understandable programming.

ps. Using assign brings the burden of having to remember that happens to return NULL. Since you didn't already think of that then using it would entail one more thing for you to remember. You already know what explicitly returning NULL means, and it's more likely that others reading your code would too.

Without a range supplied fsolve is trying to find roots from A=-infinity to A=infinity. That search is missing values very close to zero.

[edit] The situation is made more difficult due to the root lying close to a singularity, where it is steep, and with the expression nonreal on its other side.

Download A_ac.mw

Here are two ways:
1) using plots:-odeplot directly with the sol1 returned by dsolve.
2) using plots:-spacecurve with procedures returned in sol1 by dsolve.

The second way requires some use of eval to extract the various results (after applying procedures at a numeric t value). There are a couple of ways to do that. I show one way that utilizes the output=listprocedure option. It can also be done without that option, using eval slightly differently. The first way looks simpler to me.

Download unable_to_evaluate_ac.mw

@Syed Asadullah Shah

Your code doesn't initialize F (or T) as an Array, so your assignments to indexed references cause a table to be assigned to F (and T). But your code also shows F(k+2) , which is nonsense. What do you intend by that?

Your attempted second call to pade (inside the solve call) is messed up 2D Input, and is actually being parsed as pade*(...) . You could get rid of that multiplication.

The n that appears in the expressions returned by your procedure gnrpoly is the local variable n of that same procedure.

That escaped local name n is not the same as the global name n, which you are trying to use for substitution at the top-level. That is why your calls to eval are not making a substitution.

There are several ways to fix your issue.

One approach is to utilize unapply (w.r.t that local name n) inside gnrpoly, and have gnrpoly return a procedure. Another way is to pass in the variable name (eg. n, from the higher level) as another parameter of gnrpoly. Below I show the former approach, with unapply.

Download Q_10-10-22_gentrate_eqn_ac.mw

ps. You used the term "inert". This is not an issue of inertness.

I disagree with your claim that "foo() has z" used.

The only z that foo "has" (apart from its declaration as a local of foo) is as a parameter of an anonymous procedure defined and used within foo. And that is not the same z as the local z of foo.

The local z of foo is not used within foo.

An alternative is,

  plots:-textplot([2,2,InertForm:-Display(%floor(5.5),'inert'=false)])

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