Firstly, you appear to mean B*r and N*g, but you mistakenly had the two-letter names Br and Ng.

The following gets the float-point result quickly, using the inert Sum and Product commands,

Download brn_ac0.mw

Here's another way to get that floating-point approximation, with an exact special-function representation in terms of hypergeom. (And evalf acts quickly on that hypergeom representation.)

Download brn_ac.mw

The int command has an option continuous that can deal with this example.

Download Eval_definite_integral_ac.mw

You had several syntax problems, eg,
   - You had = instead of := where you were trying to assign to Profundidade
   - You had multiplication symbols before the opening brackets when trying to call SensibilidadeK,
etc.

There may have been other mistakes that I did not find. Check the results.

Download code1_1_ac.mw

That symbol is available from the Large Operator palette.

If you combine it with the Accents and Layout palettes you can construct that as 2D Math. (Optionally your can right-click convert it to an Atomic Variable.)

Download LrgOperator_ex.mw

Are you also wanting it to be hooked up to some specific command, and if so, which, and for what concrete example?

A variant,

A := {3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43,
      47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97, 101}:

select(x->x mod 3 = 1, A);

      {7, 13, 19, 31, 37, 43, 61, 67, 73, 79, 97}

Is this OK?

FicheGraphique_ac.mw

You are mistaken in your claim that this is a bug.

If you are studying integration then you should certainly learn about the (arbitrary)  constant of integration, as it relates to examples like yours of indefinite integration.

You should understand that your indefinite integral has infinitely many solutions -- differing, each, by value (that is constant wrt the variable of integration) -- because the derivative of such a constant term is zero.

This is not something special to Maple; it's a mathematics thing.

Download indef_int_ex.mw

ps. Please don't submit both a Post and Question for the same example.

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)));