@ceeeb It wasn't just a hint, IMO. I explicitly explained that the 2D Input sigma' instances were different (and how).

ps. I deleted the eight extra copies of your response.

Please stop posting multiple Question threads on this.

If you have followup queries then please put them here, instead of spawning wholly separate new Question threads on this.

@Jack D Well, the first thing is that I used fsolve instead of solve.

The maxsols option of fsolve currently works for a finite range, so I supplied such, admittedly based on a visual plot. (I could also have used m=-100..100. It's generally faster if it's not unnecessarily wide. Seems I could have used -10^6..10^6 as well.)

No, I didn't specify a starting point.

@dharr Another possibility is,

   simplify(convert(bdifxzero - bdif1xzero, abs))

Since your conditions are that re>0 and im>0 and im+re<1 then why make it work harder for the ranges out as far as re=10 and im=10?

The triangular domain can be handled with a special wrapping procedure for the plotted function. Instead, a variable range end-point can be used.

plot_NULL_warn_etc.mw

ps. It's not always necessary but it's a good practice to put interface calls in a separate paragraph or execution group than a restart. Sometimes it is necessary, for the GUI to adhere to it.

@JAMET You have some syntax mistakes.

For example,

    display*[textplot*(

Those are multiplications, not the start of function calls.

@jalal I have deleted a duplicate Question thread of this.

@Ronan You are free to do what you wish, since it's your procedure.

But note that you haven't informed us completely what the specification of your procedure ought to be. I also didn't see anything in the Questions original code or description that would make an extra argument like name foo be invalid. Maybe there are more problematic cases, in your actual, motivating project.

I don't know why you want to force argument `foo` (a name) to be processed as if it ought to be checked against the specification of parameter c. I mean, you can if you want to. For example,  coercion_ex2b.mw
But suppose you have several optional ordered parameters. It might get confusing. If you're specifiying a optional parameter with a base type and a default value (as you did, originally, GeomClr) then why must any argument be checked against its spec and throw an error if not coerced? What if that argument is supposed to be used for another parameter later down the line? I'm not saying all that would definitively be wrong. But I don't know your final goals and requirements in all detail.

One alternative for handling unexpected parameters is to write $ at the end of the parameter specifications. That makes an error get emitted if there are any arguments left over (after parameter processing against the specs...). The error message is reasonably legible, IMO.

Download coercion_ex3.mw

I realize that we're just discussing possibilities. But if have more complications to pose then I suggest that you first write down and specify the exact behavior you're after, for all parameters of your actual problem, in full. Then, if you have problems attaining that behavior, show it all.

Here is one way of getting an error emitted. You may customize it.

Download coercion_ex2.mw

@nl4l1f3 Please note that the procedure P adjusts what you originally called Ncr by the Ncr0 scaling factor.

And that's what gets put in the 3rd column of Matrix M, although the heading of that column is "Ncr". You could easily remove that scaling from P by, if you'd like.

I figured that would be somewhat easier for you than if I'd left it out of P and you wanted to add it later -- because Ncr0 depends on A's value.

@dharr I wrote, "...when the D(...) comes back unevaluated."

I also wrote, "FWIW", because I thought it maybe worth mentioning in this context. You'd mentioned using fdiff in some check.

But for this example D actually computes a derivative (operator) and does not return unevaluated. So your evalf(D(...)(...)) example is just using that computed operator's internal formula, not fdiff. No contradiction with what I wrote.

Sorry if it sounded as if I was stating that fdiff was necessarily in play here. I mentioned it only because you had cited it relating to a possible check.

With uneval quotes your example will call fdiff via the mentioned hook. But the finite differencing computation can have a hard time too close to zero here.

Download D_fdiff_ex.mw

@dharr FWIW, evalf(D(...)(numericvalue)) is a hook into fdiff, eg. when the D(...) comes back unevaluated.

@MaPal93 MakeFunction is just another name for the unapply command, new in Maple 2023. You can replace it by the word unapply in your Maple 2022.
MaPal93approx_M2022.mw

You could upload and attach a worksheet that shows your progress so far. For that you could use the green up-arrow in the Mapleprimes editor.

That would allow others to suggest looping/seq/Matrix-initializer/etc solutions, with less unnecessary guesswork, esp. with regard the nature of your function.

Would you also be interested in a 3d plot of the surface, ie. Ncr as a function of A and B?

You could upload and attach a worksheet.

@vv I get those exact sames results using either Maple 18.02 or Maple 2018.2.