Apparently the two-argument variant of EllipticE gets covered under EnableTypesetRule with the token,
     "EllipticE2"

So, that case gets covered for me (M2023.0) if I instead do it as,

   Typesetting:-EnableTypesetRule({"EllipticE", "EllipticE2", "EllipticF", "EllipticK"})

You can also enable it for all the special functions about which it knows, with,

   Typesetting:-EnableTypesetRule(Typesetting:-SpecialFunctionRules)

I don't know why the 2-argument E and F are not rendered in bold.

I will submit a bug report against the lack of bold, and the lack of documentation on the Help page about the multi-argument variants.

ps. I also see that "EllipticF" is adequate to cover its (sole!) 2-argument case. The naming scheme thus seems a bit unhelpful. But there's enough documented detail to see that this aspect is key. (It's also seen in the Typesetting:-RuleAssistant's popup details...)

The problem appears to lie in the new (Maple 2022, default) adaptive=geometric algorithm.

If you force the (older default) adaptive=true then the whole region gets plotted.

Download PlotIssue_ac.mw

I will submit a bug report against this example.

note: For this example it happens you might also use adaptive=false, though in general (other examples) that will not attempt to refine the curve near portions with high curvature or save space in portions that need fewer points.

See also the adaptive Help page.

Here's a kludge to make the datasetlabels=contents result look a bit better.

This is customized for this example, and won't handle many more elements without further adjustment/tweaks and/or reduction of font size. To be more general it would have to do more work, eg. also act according to where the "content" strings occurred, etc.

Download DigVenn_ac.mw

Here are two simple alternatives, for your example. I'd generally favour the former over the latter.

restart;
decisions := "accept", "reject":
T := 2:

`if`(1 > T, decisions[1], decisions[2]);

               "reject"

eval('`if`'(1 > T, decisions));

               "reject"

You asked why your problematic situation occurs. The `if` command has special evaluation rules, in which its arguments are not fully evaluated up front in the usual way.

One common motivating example for this design is that NULL can be passed (including the case of NULL as a 2nd argument), with the separate arguments recognized. If the argument sequence were flattened in the usual way during up-front evaluation then the following example would not work as intended.

restart;

map(u->`if`(u>2, NULL, u), [-3,7,1,9]);

          [-3, 1]

Here is another example, in which the desired behaviour also relies on the non-flattening of the argument sequence (possible by virtue of the special evaluation rules). Under usual evaluation rules the following would behave like a function call with four arguments.

restart;
p1:= A,B:
p2:=C:

`if`(3>2, p1, p2);

             A, B

Note that a workaround construction like,
   eval('`if`'( ... ))
would break the functionality of the first two examples I've given, because the forced full evaluation flattens the argument sequence.

The behaviour is somewhat similar during the initial construction where you called piecewise, which also has special evaluation rules.

note. The ifelse command also has special evaluation rules, and ought to be mentioned on the cited ?spec_eval_rules Help page.

This OP's first example is documented. The assuming facility doesn't place (its temporary) assumptions on variables it doesn't see, ie. only hidden within a procedure. From the Example section of the Help page for Topic assuming,

   The variable a is inside the body of f; the assumption that a > 0 is
   not effectively used when computing f(1).
   f := x -> sqrt(a^2) + x;
     f := proc (x) options operator, arrow; sqrt(a^2)+x end proc

   f(1) assuming a > 0;
                             (1/2)    
                         / 2\         
                         \a /      + 1

   For these purposes, you can use the Physics:-Setup command
   with its assumingusesAssume keyword, or use assume itself...
 

And so,

Download assuming_exx.mw

The OP's second example is quite another matter, related to the current limits of D functionality.

You can specify a reasonable view, and get a more usuable result.

AnimationCercleTrigoFonctiTrigo_ac.mw

You could also add the discont option to the plot of tan, if you don't want to see the vertical lines at the discontinuities, eg.
    plot(tan(x), x = 0 .. t, discont)
Then you could get,

In your Maple 2021 the values of F can overflow if computed at hardware float double-precision, for the upper portion of your range omega=0..200. That makes the upper portion of the plot blank, ie. missing the curve.

There are a few ways around that. One of the simplest approaches is to set Digits:=16 (or higher) at the start of the document.

If I do that in Maple 2021.2 then the following plot appears when I re-execute the whole document:

Plot_determinant_value_vs_omega_ac.mw

In current Maple 2023.0 the numeric problem in hardware double precision is dealt with automatically, and the upper portion of this curve is handled ok by default.

Also, the error message you showed indicated that at some point you may have accidentally assigned the value 160 to the name omega. You'll need to keep that name omega unassigned if you intend on using it as the plotting variable.

Notes: By default setting Digits:=16 allows software floats to be used in the compution of F during plotting, with a wider range of values attainable without overflowing and generating Float(undefined). Another simple alternative is to set  UseHardwareFloats:=false  .  There are also slightly more complicated approaches, including reformulation of the expression F.

@bobvandijk The back-ticks are not visible in the 2D Output if one uses Maple 2023.0 (which is the version that Carl usually uses).

The back-ticks appear in the 2D Output for this kind of subscripted display (double-undescore) in Maple 2022 when using the default setting,
   interface(typesetting=extended):
It is possible to get the atomic name `A__b,c` to display without the backticks visible in 2D Output in Maple 2022, if one uses the setting,
   interface(typesetting=standard):
however I don't particularly recommend that adjusting that to the non-default setting; you might well find something else which you don't care for if you use it.

If you go with the alternative indexed name A[b,c] which also displays as a subscipted name in 2D Ouput then note that you can also enter that in subscripted form in 2D Input mode.

You could do that with the following keystrokes, and a single-underscore:

     A  Ctl-Shift-underscore  b,c

Download sbscr_M2022.mw

It looks like you've used Maple 2015.2, for your attachment.

But the examples work ok for me using Maple 2019.2.1 (or Maple 2023.0, for that matter).

DocumentTools_and_Background_M2019.2.1.mw

ps. I did adjust one of your examples to be a Table inside a Group. rather than in an Input (a minor change, not directly related to your issue).

pps. I suspect that the issue in older versions <= M2018.2 is a GUI problem with actually embedding the content. The content results like InlinePlot(T[1]) seem structurally ok, and decode ok.

Here's one way (given what you've done so far):

dont_get_it_ac.mw

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