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);

In Maple V you could also set the _EnvExplicit environment variable before calling solve on this example.

restart;                             

_EnvExplicit:=true:

solve({x^2+y^2=3,x^2+2*y^2=3},{x,y});

                                1/2                 1/2
                   {y = 0, x = 3   }, {y = 0, x = -3   }

That's one alternative to using the allvalues command on the result (for this example) where the RootOf appeared, which has already been given in another Answer.

Since you're apparently already using a 3-component custom color for the shading of the surface, how about making that produce "black" for a controlled subset of the (x,y) points?

That is, with your HSV coloring expressions, you could set the V component to 1 or 0 in a piecewise fashion. The resulting black lines would be part of the actual surface, and not be hidden. And you could have as many or as few as you wish, regardless of the fineness of the grid option.

Here's a simple example,

3dcolorgrid.mw

You may choose to further restrict the thickness (width) of the lined black portions -- using derivative values -- if the surface becomes very steep.

The name e has no special meaning for Maple as 1D plaintext input. It's just another unassigned name.

As plaintext code you'd need to enter that with exp(x) instead of e^x, if you want to raise x to the base of the natural logarithm.

There document you attached seems to have a corrupted and unclosed Input at its end.

If I delete that problematic fragment and close off the outstanding Sections then I get to the following (which I'll try and attach both zipped and as is). It end with the subsection "Lektion 18 Tyngdepunkt af volumer".

I saved it last with Maple 2017.2 (since yours was last saved with Maple 2017.1).

1._sem_Maple_-_Kopie_ac.zip

1._sem_Maple_-_Kopie_ac.mw

restart;
de := diff(y(t),t,t)=-1:
ic := y(0)=1, D(y)(0)=0:

Events := [y(t)=0,
           diff(y(t),t)=piecewise(abs(diff(y(t),t))<1e-2,
                                  abs(diff(y(t),t)),
                                  abs(0.5*diff(y(t),t)))]:

dsol := dsolve({de, ic}, numeric,
               events=[Events], range=0..5):

plots[odeplot](dsol, thickness=3, color=red);