I am not aware of a programmatic facility to set the global FPS that one sees in the Animation part of the GUI's main menubar, dictating behavior for whatever inlined animation may be currently in focus (via the mouse-pointer).

However, if you put your animation into a PlotComponent then you can programmatically set the delay between frames, using the delay property.

That's close (but not quite equivalent) to the reciprocal of FPS, since (I believe) it's a delay from the moment one frame's rendering is finished and the next frame's rendering begins. That's not quite the same as the time between when successive frames rendering begins -- it's not quite the same in the frame itself takes longer to render.

Here's an example in which I inserted the PlotComponent by using the Components palette in the left-panel.

anim_delay.mw

With that approach you can programmatically adjust the frame-delay, from the worksheet, even while it's being played. You can also set multiple animations playing in different components, and adjust their frame-delays separately. You can also set the frame-delay for a component before assigning an animation as its property and start it playing.

You should also be able to programmatically construct and embed the Component+animation, with a delay specified at creation time. In the following example the specified delay doesn't seem to get picked up the first time I play it, unless I stop/switch focus. A pity. However, after refocus it works as intended. And the previously mentioned programmatic controls also work here.  anim_delay_EPC.mw

I might also mention that, AFAIK, for a usual inlined plot/animation, the FPS is not stored as part of the worksheet.

Amongst other solutions, you could use,
   'f'(x)
   Typesetting:-Typeset(f(x))

Your original used `f`, which is just the name f and offers no guard at all against the unwanted evaluation of f(x). using your operator assignment to f.

You might have intended single right-ticks (aka uneval quotes) like 'f', instead of single left-ticks (aka name quotes) like `f`. It might be useful to review the purposes and functionality of Maple's various quotes.

AnnotationDérivées_ac.mw

There are several other, alternative, solutions, including,
   InertForm:-Display('f(x)')
   "f(x)"

Personally, I am not a huge fan of the solutions 'f'(x) and 'f(x)' since the single right-tick unevaluation quotes are ephemeral and can get too easily stripped off by accidental full evaluation (eg. reference at the top-level, passing as argument to procedure call, etc). I prefer the solutions that transform the expression into a pure type-setting kind of construct, which the other two mentioned approaches do.

The above are all programmatic solutions. If you are using 2D Input mode then a mouse-driven, manual, alternative is to select the expression f(x) where it appears at the appropriate place in your input, right-click, and use the menu choices,
   2-D Math -> Convert To -> Atomic Variable

Download TSRule.mw

Here are some adjustments, which seem to allow the it to work in my Maple 2023.0 (especially important being the solve call.)

Download sssss_ac.mw

Here's one way, keeping fractions together, eg. sqrt(3)/2 instead of 1/2*sqrt(3).

I also changed the t15 textplot as an example of how the irrational fractions in those textplots could be handled more simply.

And I added some dotted grid-style lines to show that the tickmarks are passed through.

Adjust, to taste.

CERCLETEST_ac.mw

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)