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?

A staple command for this kind of task, used throughout the system Library code, is indets.

It can be used for a variety of extractions, depending on the type supplied as its second argument. There is even an example on its help-page, using the type specfunc, described as "efficiently selecting all occurrences of functions... from an expression".

I threw in a y(x,x) term, in order to ensure that case got covered. I'm guessing that you'd want to reject term that too.

Let's just generate a set of all the invalid calls to y. (If it's empty then you're OK.)

restart;

expr:=y(x,x)+y(x)^2+x+y(x)+2*1/y(z)+sin(x)+sin(y(x))+y+f(z)/Int(sin(y(x)),x)+y(x,y,z):

# You could generate the candidates using a simple call to `indets`.

cands := indets(expr, 'specfunc'(y));

           cands := {y(x), y(z), y(x, x), y(x, y, z)}

# And then you have a variety of ways to call `remove`.

remove(u->[op(u)]=[x], cands);

                  {y(z), y(x, x), y(x, y, z)}

remove(type, cands, identical(y(x))); 

                  {y(z), y(x, x), y(x, y, z)}

remove(u->u=y(x), cands);

                  {y(z), y(x, x), y(x, y, z)}

remove(`=`, cands, y(x));

                  {y(z), y(x, x), y(x, y, z)}

# Or you could do both steps at once, using `indets`
# with a more involved (structured) type.
#
# Note that this is not the only type that would suffice.
# I just wanted it to be simple, and comparable to one of
# the `remove` calls above.

indets(expr, And('specfunc'(y),Non(identical(y(x)))));

                  {y(z), y(x, x), y(x, y, z)}

Could you possible use a wrapper to invoke PDEtools:-Solve ? Something like this, perhaps,

Do you specifically want behaviour such that if you were to call PDEtools:-Solve a second time with identical arguments then it would produce the same results as the first time?

restart;

H:=proc()
  if not assigned(`tools/genglobal/name_counter`[':-_F']) then
    `tools/genglobal`(_F);
    if not assigned('_F0') then `tools/genglobal`(':-_F'); end if;
  end if;
  subs([':-_F1'=`tools/genglobal`(':-_F'),
        ':-_F2'=`tools/genglobal`(':-_F')],
       PDEtools:-Solve(args));
end proc:

H( D[1,1](y)(t,x) + y(t,x) = 0, {y(t,x)} );

           {y(t, x) = _F1(x) sin(t) + _F2(x) cos(t)}

H( D[2,2](y)(t,x) + y(t,x) = 0, {y(t,x)} );

           {y(t, x) = _F3(t) sin(x) + _F4(t) cos(x)}

H( D[1,1](y)(t,x) + y(t,x) = 0, {y(t,x)} );

           {y(t, x) = _F5(x) sin(t) + _F6(x) cos(t)}

H( D[2,2](y)(t,x) + y(t,x) = 0, {y(t,x)} );

           {y(t, x) = _F7(t) sin(x) + _F8(t) cos(x)}

It doesn't have anything to do with error, per se. The behavior you describe would be the same with any statement appearing after the TSprintf call in procedure foo.

You're just seeing the effect of making the TSprintf result be the final return value of calling foo(...);  with a semicolon, or not.

Just use,

print(TSprintf("Solving ", _passed));

inside foo, instead. Then follow that with whatever else you want, inside foo.

This has nothing special to do with TSprintf or Typesetting:-row. It relates to how other expressions also would get printed (or not) from within a procedure.

I suspect that you wouldn't be surprised by any behavior in the following examples, which amounts to the same causes and effects. I could just as easily use F(x) instead of x below.  And I could just as easily use an unevaluated call to Typesetting:-row instead of x below. It is not relevant to these examples how the Standard GUI renders the expression sent to print. You problems above are not related specifically to the rendering of the expression as typeset 2D Math. What matters here are just the usual rules for when/how intermediate results can get printed within a procedure.

restart;
foo := proc()
  x;
end proc:

foo();  # I see the x!!
                               x

restart;
foo := proc()
  x;
  error "oops";
end proc:

foo();  # I see don't see the x, because I didn't print it!!
Error, (in foo) oops

restart;
foo := proc()
  print(x);
  error "oops";
end proc:

foo();  # I see the x!!
                               x
Error, (in foo) oops

restart;
foo := proc()
  x;
end proc:

foo();  # I see the x!!
                               x

restart;
foo := proc()
  x;
  bar;
end proc:

foo();  # I see don't see the x, because I didn't print it!!
                              bar

restart;
foo := proc()
  print(x);
  bar;
end proc:

foo();  # I see the x!!
                               x
                              bar

It seems that one of your questions is why is~(A,B) makes an "element wise comparison".  That's what the tilde specifies -- an element-wise application of the is command.

As for why you can use the MatrixMatrixMultiply command on a mix of Matrix and Array, there is a coercion parameter-processing modifier on the first and second arguments. (See below, the last entry in the overload.)  Not all commands have such coercion. Several LinearAlgebra commands do -- I suppose as a convenience -- but I wouldn't be surprised if documentation of the fact was lacking. See also the Help topic ?updates,Maple16,coercion .

Note that for A an Array the behaviour of A . A is elementwise.

Download Matrix_or_Array_ac.mw

It's not clear to me whether you understand that several of your latter examples do indeed exhibit bugs in their code. They will break if one class of the problematic names have been assigned a value at the higher level from which you call them.

It often indicates a bug in the code, if you get the following kind of messages from maplemint (or stand-alone executable mint). And for your last example and your second-from-last example these message do indicate mistakes in the procedures.

   These names were used as global names but were not declared:  x

   These names were used as global names but were not declared:  
     axes, none, orientation, projection, scaling, unconstrained

However I agree that maplemint messages can be very long and hard to decipher. That's why the stand-alone executable mint (which reads plaintext files of Maple procedures' source code) has several options to control the verbosity. I find those options very useful, and can't imagine using mint easily and effectively without them. I am excited to see that maplemint had been revised to handle more modern Maple language features, but I am disappointed that the various options for fine control of the verbosity are not supported.

A few years ago I wrote and posted here a procedure which could invoke the stand-alone mint executable on a defined procedure. (It writes the procedure out to a file, temporarily, and then invokes stand-alone executable mint on that.)

[edit] This procedure was originally mostly intended as a proof-of-concept, or at best intended only for short examples. I think that long procedures or modules/packages are better implemented in plaintext files anyway, in which case the stand-alone mint executable can be run from a terminal shell. [end of edit]

Here's an example of using it. Note that it uses the default "info level" option of -i 2 when calling the mint executable.

Note also that the help page for mint describes option -t 13 as toggling off/on this kind of message: "These local variables were used but never assigned a value". In my experience that message quite often does not indicate a coding error, since your latter examples' situation is common: declaring a dummy variable (as in your x and y, used in a call to some other command) as local.

It might be interesting to have a discussion about whether toggles 10 through 15 are usually indicative of serious coding errors.

restart;

mint := proc( f,
  {level::posint:=2},
  {toggle::list(posint):=[]},
  {header::truefalse:=false},
  {extras::string:=""} )
local fname,k,oldiface,executable;
   fname := cat(kernelopts('homedir'),kernelopts('dirsep'),"minttemp.txt");
   #fname := "/tmp/minttemp.txt"; # or some other temp location
   oldiface := interface('verboseproc');
   interface('verboseproc'=3);
   writeto(fname);
   printf("%a := %a:\n", f, eval(f));
   writeto(terminal):
   fclose(fname);
   interface('verboseproc'=oldiface);
   executable:=`if`(kernelopts('platform')="windows",
      cat("\"",kernelopts('bindir'),"\\mint","\""),
      cat(kernelopts('mapledir'),kernelopts('dirsep'),"bin/mint"));
   k:=ssystem(cat(executable, cat(" -i ",min(level,4)," "),
                  seq(cat(" -t ",x," "), x in remove(t->t>32,toggle)),
                  `if`(not(header)," -q ",NULL),
                  " ",extras," ","\"",fname,"\""));
   if k[1]>=0 then printf("%s",k[2]); end if;
   NULL;
end proc:

foo:= proc()	
    local p,x,y;
    p:=plot3d(sin(x)*cos(y),x=0..Pi,y=0..Pi,
              axes = none, projection=0.9, 
              orientation=[-30,55,0], scaling=unconstrained
              ):
    p:
end proc:

mint(foo);

 Procedure foo() on line 1
   These names were used as global names but were not declared:  axes, none, 
       orientation, projection, scaling, unconstrained
   These local variables were used but never assigned a value:  x, y

mint(foo, toggle=[13]);

 Procedure foo() on line 1
   These names were used as global names but were not declared:  axes, none, 
       orientation, projection, scaling, unconstrained