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

@mmcdara 

You wrote in your worksheet, "The fact the OP did not wanted the "big red block" was for aesthetic reasons, not to remove a spurious pattern." But that does not necessarily follow from the text and titles of the original Question's and the OP's first response to your Answer. It might be true, but the text from the OP does not imply it.

What was actually given includes, "Im trying to replicate a shape in maple but everytime i plot it i get a big red block of line and i don't know why." and, "How do i remove the big red block i get when using multiple variable piecewise Implicitplot?"

The OP asked how to remove the red block. I gave a way that did that successfully. I know how and why it worked, and I also know why I did not use some particular choices of numeric values for the default; that was not fortune -- I also already knew why some close approaches do not work quite the same, especially (but not only) w.r.t. borders.

I also answered the given question about why the red block happens.

@BekkiRR The .gif file that Maple exports is an animated gif. It plays in most image viewers.

There seems to be some hints about using such in PowerPoint, eg. here.

(Much more involved might be exporting each frame as separate static image files, then using a 3rd party application to combine into some video format...)

@C_R Historically this kind of thing can be related to one or more of several different factors, eg.
- operating system
- video card drivers
- resolution mode
- anti-aliasing (Tools->Options-Font anti-aliasing)
- typesetting level