@mmcdara The last time I checked, with utilizes an undocumented internal utility named bind, to rebind the export names. That makes the binding/unbinding of with/unwith work like a stack (FILO, First In Last Out).

@mmcdara 

If a name is an export of more than one loaded package then the effective binding for that name is that of the last one loaded.

Thanks for the color adjustment. I originally had it as you suggest, but later got lazy trying to save a little space... I've corrected the file. The key thing is that such colorings are quite easy.

@Axel Vogt Yes, it produces that form from Maple 16 to Maple 2022.2, but not in Maple 2023.2.1 and Maple 2024.0.

@Ronan You asked about improving the quality, and to my eye it's visually clear that the transformed 3D instance of your 2D plot collection has much better quality than the intersectplot 3D results. That was my main point, about transform.

I added an after-note, as a minor secondary consideration, is all. If you do it right then you can beat implicitplot (which is what I referred to as a hammer, not intersectplot) in terms of both computational time and memory to store the final result. If you end up animating, or manually rotating many larger objects in a GUI plot, then these things can make a difference in performance. That might not make any significant difference to your small example here; I mention it only as a potential going concern. If efficiency is not a concern in this then you can just ignore the whole commentary.

I wrote "line, or even plot with..." before. That does not mean that plot would be my first choice. With line you can construct a small structure quickly. Here's another:

with(plots):
# you might re-use either of these
L := rhs(isolate(-(13*x)/12 - (5*y)/8 + 71/96,y));
xrng := [-3,2];

# I personally don't find this next one too complicated.
# If you have many such L formulas then this could be
# done some with some simple added `seq` action.

pointplot([[xrng[1],eval(L,x=xrng[1])],
           [xrng[2],eval(L,x=xrng[2])]],
           style=line,color=red);

Of course you may well prefer shorter code at the expense of some time and memory. There's nothing wrong with that in your given example.

@Andiguys

I made corrections to your worksheet (and added a couple of plots you requested).

But the optimization approach was what you set up, not me.

Your overall goal is unclear. See my Reply above (May 30) to your original Question, which you still have not answered properly.

To me it seems that you use some names in contradictory ways.

Please put your followup and closely related queries on this here, or Branch from here (there's a button for that right below your Question), instead of spawning a wholly separate new Question thread for it.

A few notes:

Download eval_zero_power.mw

@vv I have reported it. Your last sentence seems to sum it up.

Another case to deal with,

evalc(0^n);
Error, (in type/complex) too many levels of recursion

@Ronan Thanks.

I added a couple of shorter ways to do your given example to the start of my Answer.

@Ronan The structure of my type-check was as follows:

  type(...,
            And(                            # it must pass all the following
                      name,                # it must be of type name
                      Not(constant)   # disallow Pi, gamma, etc
                      satisfies(mine)  # return true when mine is applied to it
                    )
         ) 

Here's some explanation of my use of type satisfies. This type allows you to utilize a custom procedure as the predicate of the type-check. That's very flexible and powerful.

Download type_satisfies.mw

@C_R Were you trying something like the following?

(evalc takes the unknown a as real)

(we can optionally simplify the signum(a)^3 to just signum(a), for a little extra clarity)

Download C_R_polar0.mw

@MaPal93 

I mean,

  max( 0, min( 10, Z(X,Y) ) )

That makes only the range 0..10 be used for applying your shading scheme. You get to see actual green even if Z(X,Y) would produce a huge value otherwise for some X,Y in domain.

It can also fix the flashing that the GUI can have when rotating 3d plots in such situations of massive out-of-view values.

Also,

  view=[default,default,0-1e-5 .. 10+1e-5]

(or, keep original view and adjust added max/min cutoffs accordingly by small amount)

if necessary due to possibility of introduced flat artefact.

In the following example, the first surface doesn't actually show any green portion.

plot3d( 1/(100*(x-3)*(y-2)),
        x=2..3, y=1..2,
        'colorscheme'=["zgradient",["LightGray", "Gray", "Green"]],
        view = 0..10);

plot3d( max( 0, min( 10, 1/(100*(x-3)*(y-2)) ) ),
        x=2..3, y=1..2,
        'colorscheme'=["zgradient",["LightGray", "Gray", "Green"]]);

@C_R You can also write an extension to convert, which pulls the argument (arg) out front of a usual polar cal, if that is what you'd prefer.

With a polar call it can be further used, as usual.

Here's that convert-extension idea, and then using it alongside the print-extension from my Answer.

Also, this makes the "e" appear in upright roman, like the usual `exp` pretty-printing. (Other names pretty-print in italics.)

This "e" also pretty-prints in purple, as a visual cue, which I personally like since the underneath it's a `polar` call. Remove if you'd prefer.

Download convertPolar.mw

You can also add your content-menu items, you know. Do you want one for converting a complex number to such a form?

One could also use the inert representation from my Answer to construct a custom print-extension for polar.

In the following worksheet the returns are all still just polar(...) calls, underneath, and evalc et. al. work on them as usual. They just happen to display in 2D Ouput as the OP has asked.

Download printslashpolar.mw

Personally I would never do this for usual Maple work. It's be unnecessarily confusing, because it's not WYSIWYG. There is no visual cue that the typeset output is not as it appears. Maybe if it were in purple...

@C_R No, it's not "automatic simplification" in the sense of the Maple manuals, that'd get in your way here and would undo the direct attempt. It's just usual evaluation.

Enter exp(I*Pi) and hit return and the evaluated result is -1.

So you can avoid that evaluation by using some kind of inert representation.

1) 'exp(I*Pi)' with single right-ticks in only good ephemerally. Any subsequent full evaluation undoes it. Assigning to a name foo and only passing it around as eval(foo,1) is quite awkward. (Btw, this shows that automatic simplication is not the problem.)
2) Some hack like exp(``(I*Pi)) is often ugly. Extra bracketing as output, extra op calls to manipulate, etc. ugh.
3) This is the kind of thing and inert operations (beginning with %) are designed for; a useful way to prevent evaluation while still being able to programmatically manipulate expressions in some usual ways. If you want you could also construct it (in 1D) as %exp(I %* Pi) .

Of course you could also start off with exp(i*Pi) and then eval(..,i=I) when you wanted. Seems clunkier to me. Or something weird with, say, i:=I: followed by local I: then eval the other way. Also clunkier, IMO.

You could easily write an app in embedded components, or just nifty commands, to demonstrate all this to students. But, then, you could easily write apps to do an untold number of different things.