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.

You could make the following kinds of checks, using the is command.

Download RR_is.mw

You could also assign your disjunction (or other logical operator construction) to a name, and re-use it. Eg,

It is unfortunate that Maple 2023.0 does not have cross-reference links from the Help page for topic RealRange to the Help pages with topics assume (is) and property.

Let's suppose that you have a worksheet with some Startup Code.

The "Maple Code Editor Diagnostics" panel shows syntax errors and some basic kinds of potential issues that might arise when the code is executed. A syntax error is different from an error raised when the code is executed.

If the code is executed using the Startup Code region's menu then runtime errors get reported to the "Maple Code Editor Console".

Those distinctions are why these appear in two separate bullet points in the Startup Code documentation; they relate to two different kinds of messages.

A simple (single, say) pass through the code may allow the code analyzer (here, mint, underneath) to deduce a few common and simple kinds of potential runtime problems -- procedure locals used before being initialized, unattainable code blocks, locals assigned values but then not used, etc. These kinds of issue are reported to the Diagnostics panel.

But these diagnostics don't execute the code in full. And hence they will certainly not find all kinds of future runtime error, since doing so without actual execution is logically impossible. Runtime error message get reported to the Console panel, if executed by the Startup Code's menu.

Code can be run under the debugger. Doing so can require learning its techniques.

I would prefer to pass {x} rather than unadorned x as the second argument to solve, for consistency of output, and then fix up the conversions to RealRange.

I don't know whether you'd prefer sets or Or to be used to denote logical disjunction. Having it be denoted by mere sequences seems dodgy to me, because more involved multiple solutions could become wrongly conflated. (I don't much like T1 below returning a mere sequence...)

I also don't know whether you'd want to handle univariate examples with names other than x. It's hardcoded in T3 at present. (Also, you can't sensibly have nameless RealRanges for multivariate examples, naturally.)

I also don't know what other, future, less trivial examples you'd want to handle.

Download solve_RR.mw

You are trying to use an exact solving methodology on an expression containing float exponents. (That can make solving fully over the complex numbers be quite a demand.)

Using fsolve is more suitable here.

fsolve(.2894606222 = .4090662520/((1+0.1481289280e-2*x)^5.034901366
                                  *(1/(1+0.1481289280e-2*x)^5.034901366)^.1986136226),
       x);

          60.41863487

Also note that converting to rationals (even "exactly") and forcing it through solve doesn't really help much to getting an accurate floating-point  result here.

Download fs_1.mw

Here is a brief way to do that.

   L := [seq(cos(x), x=0.1 .. 10.0, 0.1)];
   S := sort(L);
   S[35];

which produces -0.5885011173 as its last result.

Here's a slightly longer way, that shows a bit more. (figured that you're trying to learn some Maple. You could try and work out for yourself what these commands do...)

Download sort_cos_list.mw

You may have noticed that lists L and S each contain both the x-values as well as the cos(x) values. I only did it that way because I thought that it'd be fun/interesting to be able to immediately get the corresponding x-value which produced the 35th greatest cos-value, without doing any additional computation.

You've already assigned ics itself as a set., ie.
   ics := {V(0) = -65, h(0) = 0.6, m(0) = 0.05, n(0) = 0.32}

Having done that, you could pass either,
    {eq1, eq2, eq3, eq4} union ics
or,
    {eq1, eq2, eq3, eq4, op(ics)}
to dsolve.

That merges the differential equations and initial conditions together into a single (flat) set. 

Or you could assign only the expression sequence of conditions to ics (and not itself a set), ie,
   ics := V(0) = -65, h(0) = 0.6, m(0) = 0.05, n(0) = 0.32;
and then pass your original formulation to dsolve, ie.,
   {eq1, eq2, eq3, eq4, ics}

Adjust the rest, as desired. I didn't look to see if your system and the results made sense.

Download Question1_ac.mw

Here's one way, collecting wrt the global :-diff.

The colon-minus prefix makes it refer to the global name diff rather than the Physics export going by the similar name.

Download CollectDiff_ac.mw