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

For your example of sin(x) there are infinitely many solutions, where x can be any integer multiple of Pi. You can use various options to the solve command to request either a representation of "all the solutions", or solutions within a specified real range. However it's not too hard to find examples which solve cannot handle.

restart;

solve(sin(x),x,allsolutions);

                             Pi _Z1

map(about,indets(%,And(name,Non(constant)))):

 Originally _Z1, renamed _Z1~:
   is assumed to be: integer

solve({x>=0, x<=3*Pi, sin(x)},x,explicit,allsolutions);

           {x = 0}, {x = Pi}, {x = 2 Pi}, {x = 3 Pi}

The Roots command from the Student:-Calculus1 command can also be useful here.

Student:-Calculus1:-Roots(sin(x), x=-3*Pi..3*Pi);

             [-3 Pi, -2 Pi, -Pi, 0, Pi, 2 Pi, 3 Pi]

Student:-Calculus1:-Roots(sin(x)*cos(x), x=0..2*Pi);

                   [   1         3         ]
                   [0, - Pi, Pi, - Pi, 2 Pi]
                   [   2         2         ]

Student:-Calculus1:-Roots(sin(x)*cos(x), x=0..2*Pi, numeric);

    [0., 1.570796327, 3.141592654, 4.712388980, 6.283185307]

foo := unapply( int(x*sin(n*x),x=0..Pi), n::integer ) assuming n::integer;

                                           n   
                                       (-1)  Pi
                foo := n::integer -> - --------
                                          n    

The help page for unapply has a bullet point which describes it thus: "The unapply command implements the lambda-expressions of lambda calculus."

But you can use unapply to construct both of the procedures you described ("evaluated", and not). You can even do it at the top-level, using an expression already assigned to a name.

Download unapply_stuff.mw

On a somewhat related note, this Mathematica page says, "Pure functions are a characteristic feature of functional programming. They’re often called lambda expressions, after their use in mathematical logic in the 1930s. "

Notice that data in the Array in your MESH represents values in cartesian coordinates.

You seem to be confusing the x and y in your call to plot3d with the cartesian coordinates of the rendered plot. Perhaps you should consider that the variable names in your plot3d call are just dummy names. What matters is their position in the plot3d call (as 2rd or 3rd argument), not any lexicographic quality of the dummy names.  Your plot3d example is fully equivalent to,

c := plot3d( theta*z, theta=0..2, z=0..1 ,coords=cylindrical, grid=[3,2] );

So r*cos(theta) becomes theta*z*cos(theta) since you've supplied the formula theta*z for the first argument r(theta,z). So that should explain how the x and y data values are obtained from the theta and z values (generated in your 1..3,1..2 grid-like fashion).

Now, in the [3,2,k] positions of the data Array the values for theta and z would be taken as 2.0 and 1.0 respectively.

Now compare these following values with the PLOT3D structure that I obtain (in Maple 2018.0).

theta*z*cos(theta) = 2.0*1.0*cos(2.0);

                 theta z cos(z) = -0.8322936730

theta*z*sin(theta) = 2.0*1.0*sin(2.0);

                  theta z sin(theta) = 1.818594854

c:=plot3d(theta*z,theta=0..2,z=0..1,coords=cylindrical,grid=[3,2]):

lprint(c);
PLOT3D(MESH(Array(1 .. 3, 1 .. 2, 1 .. 3,
                  {(1, 2, 3) = HFloat(1.), (2, 2, 1) = HFloat(.540302305868139765),
                   (2, 2, 2) = HFloat(.841470984807896505), (2, 2, 3) = HFloat(1.),
                   (3, 2, 1) = HFloat(-.832293673094284814), (3, 2, 2) = HFloat(1.81859485365136342),
                   (3, 2, 3) = HFloat(1.)}, datatype = float[8])))

[edited] See also MESH bullet point in the Description on the help page for topic plot,structure .

You can use the plots:-listplot command to plot a numeric Vector or 1-D Array. For example,

restart;

A := Array( 1 .. 1024, proc( n )
       local s := 0;
       local m := n;
       while m <> 0 do
           s := s + irem( m, 10, 'm' )^2
       end end, 'datatype' = 'float'[ 8 ] ):

plots:-listplot(A);

## Choose one of these.
#V:=SignalProcessing:-FFT(A);
V:=DiscreteTransforms:-FourierTransform(A);

plots:-listplot( map(Re,V) );
plots:-listplot( map(Im,V) );
plots:-listplot( map(abs,V) );

In the middle of your code you have  for j from i+1 to 4  but the  do  is missing in that line.

So the very next line, which begins with another  for , is unexpected.

Also, your code seems to be intended to assign values to certain Matrix entries like A[j,k].  But you are using = instead of := , where the former just creates an equation while that latter would do an assignment. You probably want := instead of = on those lines.  The use of = in the conditonal check if A[i,i] = 0 then  is ok.

The instances of names x and y within the expressions assigned to s or E[1] or E[2] are not the same as the formal parameters x and y of your procedure si.  So when si is called with numeric values for its parameters x and y those are not used as replacement for the global x and y inside s or E[1] or E[2].

Here are some ways that work.

names.mw

You need n:=1 instead of n=1 to assign the value to n.

From the help page for topic CodeEditRegion, third bullet item in section Steps to Inserting and Collapsing the Code Edit Region , [italics mine],

   When a code edit region is collapsed, an icon displays within the worksheet or
   document marking the code edit region, and all but the first line of the procedure
   will be suppressed. The first line of the procedure displays to the right of the icon.
   A comment may be included before the procedure to display a descriptive
   heading instead of the first line of the procedure. To suppress the printing of the
   first line of the procedure, insert a blank line on the first line of the code edit region.

The value of tanh(20.0) is approximately .99999999999999999150 to twenty decimal places.

If that is squared then the result is approximately .99999999999999998300 .

By default Maple uses a working precision based upon Digits=10. If you subtract the previous result from 1.0 then, at any working precision of less than seventeen decimal digits, the result will just be 0.0 because .99999999999999998300 would be rounded up to 1.0 before the subtraction.

See here for an explanation of this known difficulty with floating-point computation at a fixed working precision. The issue is not specific to Maple, but is quite common in scientific and other floating-point computing.

If you want the trailing digits of information in .99999999999999998300 to be retained during the ensuing stages of the computation then you'll need more than seventeen decimal digits of working precision. That is,

restart; Digits:=16: evalf( 1 - .99999999999999998300 );

                          0.

restart; Digits:=17: evalf( 1 - .99999999999999998300 );

                           -17
                       2 10   

restart; Digits:=18: evalf( 1 - .99999999999999998300 );

                            -17
                      1.7 10

So lets look at the whole computation. Here below the intermediary floating-point result for tanh(-20.0)^2 may not even be as fine as the value used above, for working precision below twenty decimal digits. So there may be roundoff error even before the above kind of loss of precision. (And so this compound floating-point computation can suffer even more, from a successive build up of floating-point error.)

restart; Digits:=16: evalf(1-tanh(-20)^2);

                          0.

restart; Digits:=17: evalf(1-tanh(-20)^2);

                           -17
                       2 10   

restart; Digits:=18: evalf(1-tanh(-20)^2);

                            -17
                      1.6 10   

restart; Digits:=19: evalf(1-tanh(-20)^2);

                             -17
                      1.70 10   

restart; Digits:=20: evalf(1-tanh(-20)^2);

                             -17
                     1.700 10   

restart; Digits:=21: evalf(1-tanh(-20)^2);

                              -17
                     1.6994 10

In stark contrast to the above, the direct computation of evalf(sech(-20)^2) does not happen to involve this particular difficulty.

restart; Digits:=10: evalf(sech(-20)^2);

                                -17
                  1.699341702 10

Note that setting Digits:=d (for positive integer d) does not promise d decimal digits of accuracy in compound floating-point computations. See also subsection "Precision and Accuracy" in section 7.3 "More about Floating-Point Numbers in Maple" of the Programming Guide. That is also available directly from within Maple's Help system.

Those %1, %2 are labels representing common subexpressions.  At the bottom you can see the values that the labels represent.

This form of the output allows the results to be displayed more briefly. It can also allow for easier visual insight into the overall form of complicated results.

You can read about it by looking for the word labelling on the ?interface help page.

You can turn it off as follows:

interface(labelling=false);