@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.)

@nm  Perhaps I misunderstood your question. If I have made a mistake here then I apologize to you for it.

I make mistakes now and then, like anyone else. Perhaps you could see your way to weighing the considerable efforts people make in helping you against their mistakes.

It duplicates your query in an earlier Question thread. It is very unproductive to split the thread, for both readers and responders. You didn't even bother to put in cross-reference links or use the Branch facility.

@nm You are mistaken; it duplicates your query here about how to make type-checking occur globally.

You didn't even bother to Branch it off (there's a separate Button for that, which you ignore). You didn't even bother to cite to earlier query here. It is very unproductive -- nobody reading either thread will know that the other exists.

I now regret mentioning objects and trying to describe a mechanism that would provide the kind of global type-checking after which you queried, if you cannot be at all gracious.

@nm If you used an object for your structure the you would get a typecheck "for free".

You can also use a Record within an object, for organized storage.

And the object's constructor could enforce the correctness of the initially stored values. 

You can also give the object some handy static methods (perhaps from some other commands in your package).

ps. I don't see why you had to duplicate your query about how to set up your type-checking as two additional, highly related, but unlinked Questions. Splitting the information isn't helpful. You could at least have put in cross-reference links, or used the Branch facility. I have deleted one of them  which duplicated your global typechecking queries.