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

What do you want the result to be, a plain Vector?

Download dfvecstack.mw

Or, if you want the result as a DataFrame, then what would be its row labels?

You main problem is confusion between operators and expressions.

Notice that in your original worksheet what actually gets assigned to f is an operator which returns a call to statevalf (without parameter x being used). That's all muddled up.

Ideally you should be using the Statistics package, instead of the deprecated stats package. Below I show how you can use either.

In the case of using an operator then there are some idiosyncrasies with using int and performing purely numeric integration. I suggest using evalf(Int(...)) instead of using int for purely numeric integration (quadrature). However, you could use int for symbolic integration of an expression for the pdf (see below).

Look carefully at how the plot and evalf(Int(...)) commands get called. When their first argument is an operator then second argument is just a range like -20..20. When their first argument is an expression (in x) then the second argument is of the form name=range like x=-20..20.

Note that, depending on your approach and the working precision (Digits), you may see some small discrepencies from the floating-point computations (eg. artefacts due to roundoff error, loss of precision, etc).

>  >  >  >  >          >  >  >  >          >  Floating-point (numeric) integration >  Floating-point (numeric) integration >  Symbolic integration (of expression containing float coefficients) >  Symbolic integration (of expression containing float coefficients) >  >  >          >  >

Download pdf_ex.mw

The catch mechanism can recognize a match in the beginning of an error message.

So you can make all your own errors begin with some key string.

Then you only need a single catch, to catch all of your own.

You can optionally rethrow the error, or rethrow some other error of your devising, or print something, etc.

And you could optionally deal with all other errors similarly, or just let them error-out, as is.

Download catch_examp.mw

Let us know if you have difficulty making do.

Download de_h_exp.mw

(I had similar success in old Maple 16.02.)

The names you give the axes are your own choice, as is the orientation. You can adjust them however you want.

Download vorZ_ex.mw

Try passing the option explicit to the solve command.

1) The link for the form to make a Software Change Request is here.

(That also has a link item, in the drop menu "More" on the Mapleprimes tab menu at top.)

2) In Maple you can return to text entry mode with the shortcut Ctl-t . Does that also work in Maple Flow?

Here's an example of using sort to alter the form in which the (unique representation) of the expression is stored in the engine.

If you have some more involved answer that presents further problems then you ought to provide us with it. It often saves time for responders as well as questioners if a concrete example to reproduce the issue is provided up front.

Download sort_term_ordering.mw

Here's a goal that someone might have:

   Take your Maple code snippet and programmatically translate it
   into another language such that the computations could be
   executed while relying only the stock runtime for that language
   (libc.so and libm.so or Windows equivalents, or a Python
   interpreter, etc), and without needing Maple in any runtime
   capability (including shared object library support, or its Library
   of interpretable commands, etc).

That's an interesting goal. A key aspect is the absence of any need for Maple proper, when running the translated code.

Note that your original Question doesn't make it clear whether you have these goals and restrictions.

There is currently no simple set of stock commands which can directly or easily accomplish the above stated goal (in italics above) for blocks of Maple code that generate its Graph structures, return its Matrix structures, or call almost all of the user-level commands of its GraphTheory or LinearAlgebra packages.

I'm guessing that by \cos^{i+2}(\theta) you intend cos(theta)^(i+2) in Maple syntax.

Download int_cos_i.mw

Are you supposing that i is an integer?  A nonnegative integer, perhaps?