No.

For single calls to elementary functions (and most special functions) there is a goal of something like 0.6 ulps.

But there is no general precision tracking, and hence no guarantee, for general compound operations.

(Also, several advanced numeric commands such as fsolve, evalf/Int, Optimization, etc, either strive for similar accuracy or have their own tolerance options separate from Digits.)

There is a very modest/small amount of facility for compound operations known to evalr. But of course that cannot be sensibly compared to the widespread facility in Mma of its own precision tracking within compound floating-point computations.

But don't be deceived about Mathematica's numeric capabilities wrt accuracy and precision. It's easy, except when it isn't. It works well, except when it doesn't. And the internet has seen many reports of quirks when it doesn't work as it's supposed to. My main problem with that is that -- since it's a closed proprietary, non-standard mechanism, purportedly based in some way on interval arithmetic -- there's often no transparent way to hold up all results and explain why they must be as accurate as claimed.

That can be accomplished with only a small edit to your original.

Also, the g(x) gets resolved to its formula, in the lhs column, just as you had it originally.

TableauValeursInterditesMaple_ac.mw

You have the 2D rendered version of this 1D code,

    D__2(R)(x,0)

in your IBC.

Unfortunately the doesn't mean anything special to Maple. It's not a correct syntax for using the D command.

You may have intended the following, instead, as a partial derivative with respect to the second parameter of R.

   D[2](R)(x, 0)

It's a somewhat common mistake, because in 2D input/output both the indexed name D[2] and the double-underscore name D__2 can get rendered as a subscripted name.

You have a similar syntax mistake later on, where you have the 2D rendered equivalent of this 1D code,

   plots__display(p1)

instead of either,

   plots[display](p1)
or,
   plots:-display(p1)

In the following attachment I've corrrected both those problems.question_1_ac.mw

If you want to enter an equivalent of D[2] in 2D Input mode, and have that input be rendered as a (pretty-printed) subscripted name, you can use the keystrokes,
    D     Ctl-Shift-_    2   (ie. Control-shift-singleunderscore)

Adjust as wanted.

Download npassed_ex.mw

[edit]
I'll mention that, like Carl's overload approach, this too avoids any awkwardness that may come from having arguments that don't match named parameters due to there not being any named parameters.

I'll also mention that the decision process (figuring out which code branch to take at run time, aka dynamic dispatching) can, in general, sometimes be much more complicated. While it might not seem so important for the simple example considered here, I have a general preference for keeping more parts of the decision process inside the Maple procedure body. For one thing, that allows it to easily be stepped through in Maple's debugger.

I do not like using redefine for this kind of task, because not only is the decision process veiled under the debugger (like with overload) but also the end result is a procedure in which the relevant decision-process is far less legible.

If L is the name of your Library archive, you could try getting the stored names which have been assigned modules as follows.

L := [libname][1]:

select(type,
  map(proc(m) try nprintf("%s",m[1][1..-3]);
              catch: end try; end proc,
      LibraryTools:-ShowContents(L)), `module`);

I don't know whether you want to recurse into those modules (using op(3,...), say), to test members for submodules.

How's this, for both locals and exports that are procedures.

H := proc(m) local res;
  local oldOM := kernelopts(':-opaquemodules'=false);
  try
    res := select(p->type(m[p],procedure),
                  [m:-_pexports()[],op(3,eval(m))]);
  catch:
    res := [];
  finally
    kernelopts(':-opaquemodules'=oldOM);
  end try;
  res;
end proc:

H(LinearAlgebra);

[edit] I ought to have used exports(m) instead of m:-_pexports which I'm also used to dealing with. I copy&pasted the wrong version from that older Answer of mine.

The corrected version would be,

H := proc(m) local res;
  local oldOM := kernelopts(':-opaquemodules'=false);
  try
    res := select(p->type(m[p],procedure),
                  [exports(m)[],op(3,eval(m))]);
  catch:
    res := [];
  finally
    kernelopts(':-opaquemodules'=oldOM);
  end try;
  res;
end proc:

That attempts to reset kernelopts(opaquemodules) to whatever it is before you call it. However, if you are planning on calling trace on such locals then you'd setting that to opaquemodules=true, anyway. In that case the key part is this,

select(p->type(m[p],procedure),
       [exports(m)[],op(3,eval(m))]);

I suppose that you could also adjust the accepted type in the select predicate, to report on appliable-submodules as well as procedures. That is, you could change the type from procedure to, say, callable . The key part would then be,

select(p->type(m[p],callable),
       [exports(m)[],op(3,eval(m))]);

Here is an example (for your Maple 18),

epsilon := [0, .176362132279649, .177972719793772, .178136769285510,
            .178248700683859, .178336529283486, .178410011515762]:
sigma := [0, 4.05415828646400*10^7, 3.98220224222089*10^7, 3.96850822603262*10^7,
          3.95890268946213*10^7, 3.95125366914829*10^7, 3.94479245392923*10^7]:

plot(epsilon, sigma,
     labels = [`ϵ`, `σ`]);

plot(epsilon, sigma,
     labels = [Typesetting:-mo("ϵ",mathsize="20"),
               Typesetting:-mo("σ",mathsize="20")]);

stress_strain_ac18.mw

I'll also mention that I deliberately did not do it in the following way. This works when done alone, but if the resulting plot is assigned to a name then any subsequent full evaluation of that gets it all messed up. (Putting uneval-quoted references to assigned names inside a plot's label is a poor idea.)

plot(epsilon, sigma,
     labels = [typeset('epsilon'), typeset('sigma')]);

That is a bug new to Maple 2023.0 .

I shall submit a bug report, if you haven't.

note: In Maple 2022.2 it can be simplified to -2/7 with the call,
   evala(simplify(expr));
or,
   radnormal(simplify(expr));
or,
   Algebraic:-Normal(simplify(expr));

In Maple 2023.0 that simplification can be obtained by any of these,
   simplify(evalc(expr));
   evala(simplify(convert(expr,exp)));
   radnormal(simplify(convert(expr,exp)));

The names segm returned by your geom(...) calls are escaped locals from that procedure. By that I mean that they are distinct instances of the local variable (only ostensibly having the same name).

The same goes for the [a1,b1] pairs that you are seeing, following the separate geom(...) calls. Those are distinct/different pairs of escaped locals.

Each time you invoke your geom(...) it returns a different instance of its (now, escaped) local segm. And the segment associated with that contains references to a pair of different instances of the a1,b1 (now, escaped) locals.

The geometry objects associated with those groups of distinct escaped locals are, in turn, also different.

None of these escaped locals are the global names, a1, b2, segm.

Download GeometrySegment_acc.mw

Your Question's code tries to catch wrt the error message starting as,
  "wrong type of arguments"

But the error message emitted by your later example actually has,
  "wrong type of argument"

Note that the last word in the emitted error is singular "argument", not plural "arguments".

It seems as if you couldn't catch it because you misspelled the last word.

Download CatchMeIfYouCan_ac.mw

Some years ago a decision was made to add argument coercion to the Matrix/Vector parameters of many LinearAlgebra commands.

(Below, note the ~Matrix rather than just Matrix, as the type-specfication for parameter A. That's the syntax for the coercion parameter modifier.)

showstat(LinearAlgebra:-RowDimension);

LinearAlgebra:-RowDimension := proc(A::~Matrix, $)
   1   op([1, 1],A)
end proc

I'm not entirely sure why it isn't mentioned on the individual Help pages of the relevant commands; it's possible(?) that someone imagined that people might find it more confusing than helpful to see it described in great detail on each such page.

note. Even the older (now deprecated) linalg package's commands accepted listlist/list even though their Help pages mostly mentioned only matrix/vector.

I am not a fan of this general and wide-spread use of coercion. It's a hidden performance penalty -- quietly allowing often unnecessary use of data structures which entail inefficient copying (casting to Matrix/Vector) on each call. Encouraging users to utilize the right (efficient) data structures -- where possible -- would be better than silently passing through on inefficient programming.

Download Convert_inert_IC_to_D_notation_ac.mw

You're getting that first example's error because the name x is already being used for statevariable. That's what the error message means.

It seems reasonable to me, to disallow using the same name simultaneously for more than one DynamicSystems meaning.

So, if you first change statevariable to some name other than x, you would then be able to set x for statevariable.

You could also change both in the same call.

Download DS_sysopts.mw

For your example you can find an exact symbolic expression for the maximum value of A, given x<0 and M>0.

You can plot that maximal value of A (for x=-5..0) against M.

If you're also interested in the percent loss of Amax (down from its value at M=1.2431) , against M, then you could plot that too. You could also adorn that in a few ways.

Download Help_percentage_accc.mw

You could also find the value of M at which Amax is 13% of (ie. 0.13 times) the reference value of Amax at M=1.2431.  In other words, 87% loss. The answer, shown below, is M=4.2553 approximately.

L87 := fsolve(perc_loss(M)=87, M=1.2431..10);

         L87 := 4.255250652

A87 := evalf( eval(Amax,M=L87) );

         A87 := 0.272216303

# check
evalf( ( eval(Amax,M=1.2431) - eval(Amax,M=L87) )/eval(Amax,M=1.2431) );

            0.8700000001

# check
evalf( eval(Amax,M=L87)/eval(Amax,M=1.2431) )

            0.1299999999

Download SMMS_ac.mw