Here is what there was, up until the point of corruption (in a Plot Output).

This attached is essentially the same as what the Standard GUI of either Maple 2016.2 or Maple 2018.0 are able to recover, plus one additonal trailing paragraph of 2D Input that I could salvage.

But the next Output onwards, to the end of the file, is corrupt and lacking information.

I've left it as 2D Input and a Document.

PLOTS-SOLID_ac.mw

ps. Why do you not install the 2016.2 point-release , which is a free download if you already have a licensed copy of Maple 2016.0? It may not have prevented this corruption example, but perhaps it's a good idea regardless.

Why are you not telling us specifically what you intend on doing with the intermediate expression (with the additional abs calls in it)?

It is not helpful to hold back such additonal information, which can make someone's suggested approach work -- or not -- in your broader endeavor.

Apart from not wasting responders' time, there's also a good chance that they might suggest a better way to approach the larger problem.

In the absence of those extra details about your intermediary computations, I'll throw in the following suggestion below.

Note that you can make use of a terse calling sequence to the op command, in lieu of the nested call(s).

Download subsindets_abs_sqrt.mw

More to the point: why can't you use some other name entirely, instead of abs?

Done in Maple 2018.0 on 64bit Linux on a fast machine.

Download plot_abs_ReIm.mw

Download subsindets_type.mw

orthopoly is a table-based package, not a module.

You could do it this way:

f := proc(n)
   uses H=orthopoly[':-H'];
   H(n,z);
end proc;

If your source for f is in a plaintext file (being read of loaded to a .mla Library) then you could also utilize the $define directive instead of uses. Eg.

$define H=orthopoly[':-H']

f := proc(n)
   H(n,z);
end proc;

$undef H

In this way the source code for f is still more legible.

[edited: a side-note for some explanation of the original issue] When the table-based package orthopoly is loaded using with the global name :-H is assigned the procedure orthopoly[H]. That's in contrast to module-based packages, where invoking with will rebind the name of an export but not assign to the global name. Eg,

with(orthopoly):
eval(:-H);
                     proc(n, x)  ...  end;

with(LinearAlgebra):
eval(:-MatrixNorm);
                           MatrixNorm

A table-based package is not a module, and doesn't have exports per se.

But the uses package statement sets up a temporary scope for the binding of the names of package exports. As such it works with module-based packages (in examples with the terse syntax like uses LinearAlgebra, where the names of all exports get rebound within scope), whose functionality relates to name binding. But it doesn't work with table-based packages (using a syntax like your uses orthopoly attempt), because Maple doesn't see exports to rebind.

exports(orthopoly);
Error, invalid input: exports expects its 1st argument, m,
to be of type `module`, but received orthopoly

It's an understatement to say that the Help page documentation of uses is thin.

See the commands andmap and ormap (either of which can handle your example deftly, depending how you negate the predicate).

For example,

andmap( u->u=0, check );

andmap( u->odetest(u,ode1)=0, [sol] );

and so on.

You can also use a user-defined operator/proc (as the predicate) which would print or store the entries (of sol, say) which fail.

If you want you can prove to yourself that andmap and ormap are efficient in the sense that they return as soon as the result is determined. (ie. andmap returns upon the first occurrence of false, and ormap upon the first occurrence of true).

Of course, if you want results for all entries then just use regular map command. Simply put the operands of that into a set, to make the summary conclusion.

You previously indicated that you were using plaintext source files. So you could use the $define directive to set the replacement for B throughout the source.

For example, at the top of your source file you can have (with no leading spaces, and no colon/semicolon terminator on the directive lines)

$define B somereallylongthingthatsawkwardtotypeeverywhere

and at the end of your source file you can have,

$undef B

In this way you can keep your source code more easily legible.

Having that be centralized in the source can also make it convenient if you subsequently decide to change the name of the submodule.

You have an extra space between the word and the open-parenthesis in,

   Bisection (x-> x + 0.001 , 1, -1, 0.001 )

That can make the input get parsed as the multiplication Bisection*(x-> x + 0.001, 1, -1, 0.001) if entered in 2D Input.

It's a bug in simplify, and I have submitted a report.

In a bullet point of the Description in the help page with topic int,details it says, "For definite integration, the list can be omitted and the ranges can be given as a sequence."

ee := Int( r, phi = 0 .. 2*Pi, r = 0 .. 2 ):      

depends( ee, r );
                          false

value( ee );     
                          4 Pi

evalf( ee );
                       12.56637061

simplify( ee ); # wrong
            r Int(1, phi = 0 .. 2 Pi, r = 0 .. 2)

The $include directive is the best way to do this, in my opinion.

But you need to remove the semicolon at the end of that $include line. (That's the immediate cause of your error.)

See the longer example in "The Preprocessor and Structured Source Files" in section  11.4 of the Programming Guide.

There you can find an example with $include. Note the absence of semicolon. The $include starts in the first position/column of a line, ie. no spaces or tabs to the left.

You may need to adjust the include path. It' can be good idea (IMO) to put code that adjusts the include path at the top of the main source file (or the script which reads the main source file).

You are mixing up globals and parameters. This example requires you to distinguish between a parameter and the global name.

Inside procB there is a parameter (of procB) named the_equation . Its value , in your problematic example, is the expression y=3 .

If you want to call procA and specify its keyword parameter then the lhs needs to be the unevaluated global name the_equation.

Inside procB, you still need to use the unevaluated global name the_equation when calling procA. But, inside procB, you have to distinguish that from the parameter with (ostensibly) the same name.

From within procB you can make that call to procA as,

procA(':-the_equation'=the_equation)

You would need the same syntax if, say, procB had an assigned local of the same name of that keyword option of procA.

Those unevaluation quotes above are not the solution here. They guard against another kind of problematic example, where the global name the_equation might have been assigned a value (at the top level, say). So using ':-the_equation' as the option keyword guards against both kinds of problem.

There are two relevant things about CodeTools:-Usage in your question: how to get the stats as assignable output, and how to repeat the calclulation.

The output option allows you to accomplish the first (as Carl mentioned), and the iterations options allows you to accomplish the second.

It's all in the Help page for CodeTools:-Usage, which is a good place to start.

You can still get the older Maplets-based plot-builder by using the command plots:-interactive.

It's the same command that was accessed in Maple 2017 and earlier with the context-menu item "Plot Builder".

And so that command provides a quick and easy way (ie. mouse-driven) to generate and/or apply a basic call to Explore of your choice of plot command applied to your expression, which is what the Maple 2017 right-click context menu item also inserted.

You can apply that command to your expression by typing it (as input in an execution group or document block), or by entering it via the item "Apply a Command" in the right-context-panel.

Somewhere I have a code fragment (for use in an initialization file, say) that adds that old Maplets-based interactive plot-builder back into the context-menu. So it could reside beside the new PlotBuilder in the context-panel, but with a slightly different name. Do you want me to dig that up?

Use the LibraryTools package to create and store the modules and procedures in a so-called Library Archive (.mla file). Do that in the worksheet where they are defined.

Then, in your other worksheets or later sessions, augment libname to include the location of the new .mla Library Archive file.

Use LibraryTools:-Create to make a new .mla file. You only need to do that once.

Use LibraryTools:-Save to store the modules or procedure within that new archive file. You only need to do this after you make any change to the definitions.

(Do Not use the savelib command for the second step, of storing the pieces in the archive. It is too awkward and it's use error-prone for non-experts. Really.)

There's an example of all this in the Programming Manual. It's the primary way that the Maple developers have designed for re-using modules between sessions.

Ignore any suggestion to store your modules/packages in the Maple Cloud, for now. Seriously. The Cloud Package Management stuff is new and buggy and more complicated than needed for this simple case. Master the basic LibraryTools to begin with.

Why load orthopoly up front?

How about assigning calls to H to p and q, then differentiating  and manipulating, and then only when you're ready substitute H=orthopoly[H] or what have you?

You could even do such substitutions more than once, on different forms of the abstract representation. Substitution/instantiation is only needed whenever you are passing it to a command that expects the explicit x, no?