You should either read the relevant documentation and Help pages, or provide us with the full details of your example.

What have you tried, so far?

@radaar If the Hessian has both positive and negative eigenvalues then the point is a saddle point.

If the Hessian's eigenvalues are all positive then the point is a local minimum. If the Hessian's eigenvalues are all negative then the point is a local maximum.

If the Hessian is positive-semidefinite or negative-semidefinite then the test is inconclusive.

@Adam Ledger You wrote, "...MTInterface has no arguments." That is incorrect terminology. What you may have intended to convey was that the procedure is defined with no parameters.

Lots of Maple procedures are defined with no parameters. And when they get called with arguments then those arguments can be accessed by the procedure in a few ways.

For example,

f := proc()
  print( nargs );
  print( seq( args[i], i=1..nargs) );
  print( _npassed );
  print( _passed );
end proc:

f( a, 4, b, 7.2 );

                       4
  
                  a, 4, b, 7.2

                       4

                  a, 4, b, 7.2

See the Help pages under Topic procedure for details.

The procedure about which you were asking used the _passed facility to reference the passed arguments.  See the line that contains procname(_passed) .

I think that you'll need to understand the basics before trying to understand advanced examples. Also, not every internal procedure is implemented in the Library in interpreted code.

@panke To address your dsolve followup question, look at my Answer's third example (as I suggested above).

Download plotproc_dsolve_ac.mw

I assume that this is merely a simple example of the concept, and that you may have some additional example in which the known procedure is more involved (and careful in how it handles all possible cases). Otherwise you could have used another, simpler mechanism for the piecewise effect.

@panke You haven't explained how you wish to use it, in detail, so you leave it up to us to guess.

I am guessing that you want to use it like a known function, in a call to dsolve(...,numeric) and that you could try the last of the ways I showed. I mean the example where RPM2 returns 'procname'(args) if tau is not of type numeric. Of course you can rename the procedure, or not.

I assume that this is merely a simple example of the concept, and that you may have some additional example in which the known procedure is more involved (and careful in how it handles all possible cases). Otherwise you could have used another, simpler mechanism for the piecewise effect.

As usual, you have left out the important details of your question.

Is your interest in univariate of multivariate functions?

Are you looking for exact results, or numeric approximations?

Are you looking for all solutions, or just a finite number (eg, one)?

Do you have a candidate example that has some special difficulty?

@naili You are treating your F as if it were a procedure/operator, but you defined it as an expression in x and y but not as a procedure/operator.

This would work, defining F as an operator.

restart;
F := (x,y) -> (sin(sqrt(x^2+y^2)))/(sqrt(x^2+y^2));
h := F(x, -1.8);
ListeHy := [seq(h, x = -10..10, 1.0)]:
ListeHx := [seq(x, x = -10..10, 1)]:
HxHy := zip(`[]`,ListeHx,ListeHy);
polyInterHxHy := CurveFitting:-PolynomialInterpolation(HxHy, x):
plotHxHy := plot(polyInterHxHy, x = -10..10, size=[400,400]);

And this would also work, with F just as you had it, ie. an expression in x and y.

restart;
F := (sin(sqrt(x^2+y^2)))/(sqrt(x^2+y^2));
h := eval(F, [y=-1.8]);
ListeHy := [seq(h, x = -10..10, 1.0)]:
ListeHx := [seq(x, x = -10..10, 1)]:
HxHy := zip(`[]`,ListeHx,ListeHy);
polyInterHxHy := CurveFitting:-PolynomialInterpolation(HxHy, x):
plotHxHy := plot(polyInterHxHy, x = -10..10, size=[400,400]);

Notice that h is the same in both versions, and so is all that follows the definition of h. It's just the first two lines that are different. Run both, and look carefully at the input and the output of the first two lines.

An operator is just a special, simplie kind of procedure that prints and can be defind with an arrow.

@itsme One of the advantages of a Maple Library Archive file (.mla) is that its contents are immediately accessible in any fresh session in which the location is part of `libname`.

In contrast, using `read` on-the-fly involves more parsing/interpreting/processing overhead. For larger projects the difference in loading time can be significant. Ie, it can get very onerous, if a slow and involved reread & reprocess is required at each restart.

Also, the $include process is supported by an "include path" mechanism which allows for multiple location trees and easily specified paths (programmatically set within Maple, or specified as options to scripts or the commandline interface).

There are several implications from the above. Eg. source repositories can be flexibly shared by multiple developers at different sites, without hard coded absolute paths, etc.

So, there is nothing outright wrong with using `read` (even on-the-fly, per restart) as a quick setup for a small, simple project. But it's a "poor man's" development system, and not best for scaling up projects.

There are some big and complicated projects and packages out there (... we just don't see their development details discussed here).

@Earl There are several commands for producing field plots. Why not use one of them (which produce arrows, in a customizable manner), instead of contourplot?!

@janhardo None of that is grammatical English, and I'm sorry but I cannot understand what you are trying to say.

@janhardo I disagree that those commands are complicated.

Taking a list of numeric values L, and producing a list of lists [p,f(p)] for every p in L , is not complicated. In fact it is a quite straightforward and rather basic example of Maple programming.

There are other ways to do that subtask. None is best. Most are straightforward.

There are also slicker (and more obscure, IMO) ways to do that subtask. Most such simple tasks can be done in multiple ways. I have tried to do several of them in ways that are more easily understood. I advise you to choose ways you understand better over ways that are slicker and terser.

@mthkvv There are also a few ideas for a programmatically generated a "Progress Bar" in this example worksheet:

   examples/ProgrammaticContentGeneration

@janhardo Yes, see the very first approach I took in the very first Answer I gave to one of your long sequence of queries. I really tried to get you to consider alternatives, and I even compared: using an Array and not. You seemed to ignore it, continuing on only with unnecessary Array clutter, in the many followups since then.

@janhardo In part ii) there is the possibility that for any of the given x-values the curve could intersect in more than one place. So I used a list and then seq to accomodate that possibility.

There won't always, necessarily, be multiple solutions for a given x-value. But there might be, for curves and ranges in general. Perhaps none of the 10 examples 7(a) to 7(j) require it. As I mentioned, I didn't compute them all.

If it looks awkward then I'd say that was because it is shoehorned into the books overall awkward use of Arrays to store temprary results.

In part i) you do not need to use all that code. I mentioned that before. You could, instead, examine the plots and estimate the ranges for fsolve individually. The book said to use fsolve for this. You don't have to try and write a compehensive root-finding approach using fsolve without any ad hoc example specific assistance. Take it or leave it.

I also wrote before that there are easier alternative ways, and I gave two of them. I showed this way, before,

Download ex_set_2_task_7_acc_part_i_short.mw

@janhardo It's interesting that you find the PlotBuilder a convenient way to construct some plotting commands. (I've heard someone else suggest that.)

When you toggle on the "show command" in the PlotBuilder it reveals the command to produce the same plot. But it doesn't include most option values that match defaults -- because otherwise almost all produced commands would look very long and awkward indeed.

So, if you change the grid option choice to, say, [27,27] then that is shown in the text version of the command call. But the [26,26] default is not shown.

There is no way to force the PlotBuilder to show the default being used for every option, in the shown text plotting call. I think that it's difficult to make such an environment work in all the different ways that everyone might imagine -- as well as make it simple and easy to use.

note. The described behaviour of the PlotBuilder also ignores any changes to "defaults" made with the plots:-setoptions command. (I'm just being more complete in description here. I don't want to distract you with a flood of details.)