If you use the command plots:-surfdata then you can easily add other (usual) plotting options.

For example, adding an option for orientation so that the X and Y values appear at the forefront.

Download curve_three_d_ac.mw

If you use Carl's PLOT3D(MESH(...)) suggestion then you might wrap that result in a call to plots:-display, to add such other options. Eg,

    plot:-display(PLOT3D(MESH(A)), orientation = [-142, 72, 0])

You are not succeeding in constructing the two sets (of scalars or scalar equations) because your indexing into Matrices EQ and V is faulty.

You wrote, "I have a set of equations gathered in a vector." But that is not true. Your EQ is a 4x1 Matrix, and your V is a 1x4 Matrix.

Download SoalNewton_ac.mw

Download Frac_C.mw

You could declare gamma as local at the top-level, to avoid conflict with the predefined constant.

You could issue this command at the top of the worksheet.

Download arg_removed_ac.mw

One objection that you might have to using normal here is that it will cause expansion of terms like (x+y)^3, etc, which can be unnecessarily expensive or even tricky to undo after the fact. (See first two examples below.) Using numer/denom has a similar issue.

It can be tricky to prevent this by using frontend. Instead, below I temporarily freeze the bases of exponentiated sums.

I do not claim that this will handle all kinds of example that you intend, since we have not been told the full class and the hardest kind of example you want handled.

Download normal_ex.mw

So, you want to compute antiderivatives, by integrating?

Download umm.mw

The above applies the input expression to a dummy name, __t. (For some other, as yet unprovided examples it might serve better to initially substitute for application on that dummy.)

For some strange reason pointplot accepts a list of lists, or a list of column Vectors, but not a list of row Vectors.

I changed it below, to use column Vectors.

I used Maple 2021.2 for this.

Download jamet_ac.mw

Download relabel.mw

Download convert_list.mw

Here are three ways, that show the numerals in upright Roman.

I don't care so much for solutions in which any numerals appear in italic, eg.
   caption=typeset("Or like this ",10^`8`)

note 1: I have utilized special display mechanisms because the input 10^8 becomes 100000000 due to automatic simplification by the kernel/engine. It cannot be prevented by delaying evalution, ie. unevaluation quotes (single right-ticks).

Download inert_exponent.mw

note 2: An alternative is to enter 10^8 in 2D Input mode, right-click and in the popup menu choose "2D Math"->"Convert To"->"Atomic Variable". That produces a pure name that conveniently happens to pretty-print just like the input, and which can be re-used in the caption. You could even do that directly in your plot call.

Download inert_atomic_variable.mw

The mechanism by which the GUI accomplishes the numeric formatting constructions is not generally documented. But quite a bit may be discovered through the debugger. (I used anames to figure out what to first start debugging...)

Below I use Maple 2022.1, with interface(typesetting) returning the default value extended, and interface(prettyprint) returning the default value 3.

Let's consider your image, showing "Scientific" with 2 "Decimal places" and 1 "Minimum Exponent Digits". I set that to be the numeric formatting for the input,
    5.123456789;
Something (perhaps originating in some streamcall from the GUI) makes the following Library call, which results in a bit of Typesetting function-call-structure which renders accordingly.

Download numformatting_stuff.mw

So it looks as if the GUI may be forming that list as value for the numericformatting option, based on the stuff in the popup menu in your image. Figuring out all the rules it may use in doing so could be a chore.

I do not know what those four true/false arguments mean, and the names of the keyword options only help so much with my guessing:
    showstat(Typesetting:-Typeset:-Kernel);

So, I believe that this is how it works. But I don't think that it's intended for general user consumption.

And figuring it out completely might be time-consuming. I doubt many people would enjoy figuring these out:
  showstat(Typesetting:-Typeset:-Tdisplay);
  showstat((Typesetting::Typeset)::Tn);
 

The behaviour for this example changed between Maple 2018.2 and Maple 2019.0.

In Maple 2018.2 and earlier, the evaluation of the expression under evalhf mode would produce an error when overflow occurred for larger values of t. Here is the default behavior in Maple 2018.2,

restart;
kernelopts(version);f := t -> 140^t*exp(-140)/t!:

   Maple 2018.2, X86 64 LINUX, Nov 16 2018, Build ID 1362973

evalhf(f(200.0));
Error, powering may produce overflow

But in Maple 2020 (and 2022.1) the default is for that overflow to not throw an error under evalhf.

restart;
kernelopts(version);f := t -> 140^t*exp(-140)/t!:

   Maple 2020.2, X86 64 LINUX, Nov 11 2020, Build ID 1502365

evalhf(f(200.0));

     Float(undefined)

In consequence, in Maple 2018 and earlier the plotting routines will detect the overflow and fall back to so-called software-float evalf-mode, and successfully generate the curve at the higher values of t. But in Maple 2019 and later that overflow doesn't generate an error by default, and so the evalhf results are accepted (including undefined results), and so only a partial curve is attained.

I am going to submit a bug report. I don't know whether this change in behaviour was deliberate. To me it seems like an undesirable change; it'd be better if the plotting worked ok by default, and expert knowledge should not be necessary in order to make it work.

There are various workarounds, for Maple 2020:
   - set Digits > 15 (and leave UseHardwareFloats at its default of deduced), so that evalf-mode gets used.
   - set UseHardwareFloats to false, so that evalf-mode gets used.
   - set the numeric event handler to throw an error on overflow, so that the evalhf attempt throws a detected error and then evalf-mode gets used as fallback.

Download plot_overflow.mw

Here's one relatively simple way.

Download unapply_nest.mw

It could be done with a more efficient result, I suspect, but not so similar to your original. And, anyway, this kind of goal has some inherent inefficiency.

[edit] For example, this is a bit more efficient:

Download unapply_nest2.mw

A terser variant on that slightly more efficient alternative is:
    f := unapply('subs'(a=aa, unapply(e, b)), aa);
although you may have wanted(?) the formal parameter of f to be named a. I wasn't sure.

That's a nice find. I'll submit a bug report.

Naturally, a central benefit of the 1-argument calling sequence of implicitplot is that one doesn't have to supply the ranges.

On line 21 of `plots/implicitplot` (Maple 2022.1) I see,

   21   names := indets(fcn,':-name');

which might be better as,

   21   names := indets(fcn,And(':-name',Not(constant)));

(Another fix for that first issue might be for depends(x-y-Pi,Pi) to return false instead of true. I don't know whether that's best.)

Then, on line 30 it calls Reasonable:-Domain:-Implicit. At various places under that it will balk at Pi which is not of type numeric. I don't know how robust/safe it'd be to change various type-checks under that to realcons. Perhaps one can get by by passing evalf(fcn_set) instead of fcn_set to the mapped argument of Reasonable:-Domain:-Implicit, although I don't know offhand whether that's really OK.

The following does a hot-edit of `plots/implicitplot`, changing lines 21 and 30 (as see under showstat). It's more a byproduct of curiosity than a recommendation...

Download impl_plot_constPi.mw

The D command can "differentiate" an operator such as your g, with respect to its first parameter (ie. x).

That is one of the primary purposes of the D command. And so your example can be handled easily and efficiently.

Download D_ex.mw