Here is one way, moving from red to the end-color (here, blue) through HSV color-space.

I'll do it for your rho, and then also for another, slightly different formula.

For the first example, I've rotated the orientation to try and illustrate that the shading gradient is orthogonal to the plane defined by that original rho formula.

Download cube_col_ac.mw

Here's another variant. This has the color go from red to blue through the RGB color-space, the proportion determined by where rho's value is between its min and max values (for the given ranges).

Download cube_col_02.mw

That can also get the previous result I showed, by commenting out the line that sets the color-space names.

I didn't make that efficient.

You could also make that work with other color-spaces like Lab or Luv, but there's be additional conversion steps (to and from, since some plotting aspects only accept the RGB or HSV).

You could also make an arbitrary coloring action, according to some scheme you want, given this ability to compute the position between min&max value. So, if you describe some other particular scheme in detail then I can show you how to use that with the above approach. (That could likely also be done using another colorscheme approach, possibly re-using colors generated from that option on a simple 2D curve for convenience.)

In your previous Question the Answer by vv contained a link to an older thread.

   https://mapleprimes.com/posts/214347-Multibyte-Characters

In that older posting there is code for another routine by vv, named SS, which leverages vv's LEN procedure to get substring functionality.

So, your current attached worksheet could be easily revised as, say,

Download substrings_ac.mw

It offers additional functionality, eg.

It's not much of a stretch to imagine that "SS" stands for SubString.

Are you just trying to compute this?

   convert( p(x)/q(x), parfrac, x )

If that's the case then could it really be that you didn't try entering the term partialfraction into Maple's Help search box?

1) It may work. Solving equations using the numerators could also produce some solutions which don't satisfy equations obtained from the original expressions, since it's possible that some solutions (of the new system) could make both numerator and denominator (in the original system) be zero. You don't want solutions which make any of the denominators zero. That might be unlikely. It's a general statement.

2) Where did you get this command which you are trying to use but don't understand? (If from another of your several threads on a common problem, why not ask there and keep the content sensibly close?)

It's mostly a composition. I don't know why its author included the evala@Norm since that does not have major effect on this example. You could more quickly just use numer(Eqs) , which produces a similar result as before if compared via normal. In that case you would not need the elementwise ~ here. The numer command gets mapped across the set of expressions automatically.

3) Your three expressions are sums of products. The numer command is performing expansion, when reforming over a common denominator. As illustration, notice for the following that the result from numer has greater length than the original,

Download num_ex.mw

It's not clear why you want these numer results in more compact form, since the next step is to pass them on to some system solver which will need to manipulate/reform as it needs.

Is this adequate for your goal?

Download ph_diff_ex.mw

Here is a shorter example of the underlying error occurring during evaluation at some kind of point of some kind of piecewise.

restart;
piecewise(abs((HFloat(infinity)+HFloat(infinity)*I)*2^(1/2)
              + HFloat(infinity)+HFloat(infinity)*I) < 1,
          1, undefined);
Error, (in sprintf) too many levels of recursion

That error relates to this:

restart;
radnormal(abs((HFloat(infinity)+HFloat(infinity)*I)*2^(1/2)
              +HFloat(infinity)+HFloat(infinity)*I)-1);
Error, (in sprintf) too many levels of recursion

And that in turn tries the following:

`radnormal/ToRadical`(abs((infinity+infinity*I)*2^(1/2)+infinity+infinity*I)-1);
Error, (in sprintf) too many levels of recursion

And here is how that error can occur for your expression assigned to ff, (the plotting internal process will construct a procedure from the expression)

FF := unapply(ff, x):
FF(HFloat(1.9954019196875001));
Error, (in sprintf) too many levels of recursion

subs(x=HFloat(1.9954019196875001),ff):
eval(%);
Error, (in sprintf) too many levels of recursion

bug_plot_may_29_2023_pw_ac.mw

note. So far I'm seeing this problem in Maple 2019.2.1 and after, but not in 2018.2 and earlier.

I will submit a bug report.

A smooth plot can be obtained reasonably quickly in Maple 2023.0 with,
   plot(evala(ff),x=-3..3);
That skirts around issues near 2 for, say,
   plot(X->eval(ff,x=X),-3..3);

I can see that rationalize computation go away for a long time, even in earlier versions.

If you need to get around this, how about one of,

   radnormal(expr,':-rationalized')

   simplify(radnormal(expr,':-rationalized'),size)

   simplify(radnormal(expr,':-rationalized'))

For example, in under 2sec on my Maple 2023.0,

Download nm_rdnm.mw

The maximize command can handle this example,

maximize( (x-4*y)^9+3*z, x=0..3, y=0..14, z=0..17 );

             19734

You could get that output if lessthan had been given its own alias, earlier.

In the sixth bullet point on the Help-page for topic alias, there is the sentence, "Finally, a sequence of all existing aliases is returned as the function value."

(You've added a .mw file Document, since I answered. If I open and rexecute it then I don't see that same output. Perhaps you had an original with prior commmands?)

Your code for it currently attempts it like,

Grading:-Quiz("Calculer la limite :",
   proc(Resp, Ans)
      evalb(limit(Ans, x = 0) = Resp);
   end proc,
   proc() local r;
      r := rand(1 .. 7)();
      sin(r()*x)/(3 + r());
   end proc);

A serious weakness of that is that it doesn't actually typeset it as a limit, and it doesn't indicate the limit point (ie, x=0).

Perhaps you could start with this adjustment to your code,

Grading:-Quiz(
   "Calculer la limite :",
   proc(Resp, Ans)
      evalb(value(Ans) - Resp = 0);
   end proc,
   proc() local r;
      r := rand(1 .. 7)();
      Limit(sin(r()*x)/(3 + r()), x = 0);
   end proc)

I presume that you plan on trying to come up with more inspired examples whose answers are not all zero.

There is a tricky issue, to many such quizzes: what are you willing to accept as the answer? Is it only the identical expression?

Suppose the answer is exact zero. Would you accept the float 0.00? What about 12^(1/2)/2 - 3^(1/2) ? What about sin(2)^2+cos(2)^2-1 ?

If the answer to another example were sqrt(3) would you accept 12^(1/2)/2 ?

If the answer to another example were x-1, would you accept (x^2-1)/(x+1) ?

There are more insidious examples of seemingly harmless variations that could get the wrong grade.

Note that it's not generally practical to attempt any simplification as strong as, say,
   evalb(simplify( limit(Ans, x = 0) = Resp ));
because for various classes of problem (integration, say) that could give the response "Correct" even if one merely entered the unsolved problem as the response!

Also unsatisfactory is, say,
   evalb(limit(Ans, x = 0) = simplify(Resp));
because there may be more than one acceptable form, and (more seriously) different accpectable forms might not simplify to the same simplified form.

Given a particular validation scheme, it's often possible to come up with an innocuous looking example for which the grading is not right.

Is this the kind of thing that you are trying to do?

note: here, you may compare,
   CharacteristicPolynomial(A,lambda);
   Determinant(A-lambda);

Download cpoly.mw

(check for typos)

Download ps_volume.mw

It's not clear whether you want, say, one of the edges of the result to be along a common ray as one of the edges of the original.

It's also unclear whether you want to produce only the transformed result directly, or whether you want to produce both (transforming the original into the result).

For example, using an orientation so as to get a view down onto the triangles,

>  restart; >  P := plot3d(v^3,u=0..1-v, v=0..1,             orientation=[-90,0,0], style=surface); >  plots:-display(   plottools:-transform((x,y,z)->[x+y/2,y*sqrt(3)/2,z])(P),   view=[0..1,0..1,0..1], labels=[u,v,""],   orientation=[-90,0,0], style=surface); >

Download 3d_tri_transf.mw

Of course you can still rotate those; they are 3d plots of surfaces.

What you've stated about reading in names containing such characters is not true. Code with assignments to such can be read in via .mpl files.

But you can run into difficulties when you try to refer to them in new input lines in the GUI. In a roundabout way you can access those assigned names, and their values, via anames(user).

However, what will usually happen is that if you copy&paste such a name into the GUI what will actually be input are more like the names,
   `ζX1` , `ζX2`

So, when you write, "...shows as unassigned" be careful that you're actually using/entering the name you intend to access. Having difficult entering the intended names does not mean that the names are unassigned.

Now, those specially formed ASCII names also happen to both pretty-print in output in the manner you've shown, in the GUI, with typeset Greek prefixes.

You can even enter those in the GUI without having to make all those extra keystrokes, by using the appropriate GUI palette for the Greek letter while in 2D Input mode.

So, one solution is to use the names like `ζX1` for your plaintext .mpl files, instead of utf-8 unicode.

In other words, use the intended mechanisms that the GUI supports and is designed for.

In the following worksheet, I read in the code you showed from a plaintext file which I named "foo.mpl". This is just an illustration of the fact that the names you originally gave can indeed (contrary to your claim) be read in via .mpl text format and assigned to.

Download uni_nms.mw

Some earlier postings by you indicated that you might still be using Maple 2022.

The following works in Maple 2022.2 (and several earlier versions as well, including Maple 2018.2 and Maple 16.02).

Download trig_simp_ex2.mw

In Maple 2023.0 your example is handled directly by the simplify command.

If it's of interest, one can observe why expanding wrt powers helps here. After the expand, the result can be factored, with one of the factors being zero by simple Pythagorean trig identity.