Inside the call to plot3d, change,

    eval(M)

to,

    eval(M,last[1])

The Help page for next mentions this at the end of its Description section,

"Note:  Multi-level next statements are not currently supported in 2-D input in the Standard interface."

One big choice is whether to make C be taken from an integer ranges (whose number of elements works nicely with the number of frames), and have the 2*Pi factor occur in the plot command's code.

Or you can keep the range C=0..2*Pi and "turn" the values back to rationals.

I'll do the latter of those below.

And even then, there are still some fun choices for customizing the tickmarks and title, to get results that may clearly illustrate the progression.

I'll disable the paraminfo option of animate, and put the rational C values back in using the title option.

Here are a few variants of that, according to whether the title appears at all values, etc. You can adjust to taste. (Note that the number of frames is a nice multiple of the number of intervals. As Kitonum explained, that's key.)

Download Q_Pi_scaling_ac.mw

One way is to utilize the Physics:-diff command instead.

Download test_funtion_diff.mw

You can do that by calling it with its long-form package name, ie,
     Physics:-diff(..., fA(r))

Or you can load it from the Physics package (as I did in the attachment).
That makes the call,
    diff(..., fA(r))
utilize it since the `diff` name is rebound to the package export.

According to whether k in formula B is even or odd, the B formula corresponds to one of the A formulas.

Download trig_e_1.mw

You can force the rearrangement of some subterms terms in your R using the sort command. This acts in-place on the internally stored structure.

You may have to forget(latex) to clear remembered results.

In the following example I first (forcibly) create the whole R expression in an order that you don't want. (Otherwise it the problem might not arise...) Thus I can illustrate the effect.

Download latex_sort_ex.mw

nb. Generally, this facility acts on sums which are polynomial in the specified names.

ps. You can also get some such effects with collect, eg.
    subsindets(R, `+`, u -> collect(u, [x, y, z]))
but note that has less control over the term constant wrt x,y,z.

Since you explicitly provide integrals over ranges where the integrand is negative (or positive), then why not shade with colors that illustrate that nicely?

A command that can do that in one call is FunctionChart from the Student:-Calculus1 package.

For example,

Download εμβαδόν_χωρίου_ac.mw

Note: If such a plot is assigned to name foo, then the following will force transparency on it:
     plots:-display(foo, overrideoption, transparency = 0.7)
Or you can simple wrap that around the FunctionPlot call.
εμβαδόν_χωρίου_ac2.mw

Of course, you can also color regions by sign, or add transparency, using just the a single plotting command and a pair of piecewise. One piecewise is undefined for f(x) negative, the other for f(x) positive. That is pretty easy, and requires no break up of the domain, etc.

Download easy_signed_fill.mw

The point is that you don't have to find all the zero crossings of f(x) and make multiple plots for the subdomains between crossings. Doing so is not hard, but it's unnecessarily complicated in general. In contrast, the piecewise-pair formula works directly, and in general.

ps. You could also use f instead of every F(x) above. I only used option remember to avoid some duplication of computation, even though these simple examples don't have efficiency concerns.

with(plots):
form := [piecewise(f>0,f,undefined), piecewise(f<0,f,undefined)]:

f := x^3;
display(
   plot(form, x = -1 .. 1, filled, color = [cyan, "Coral"]),
   plot(f, x = -1 .. 1, color = black, thickness = 2) );

f := x^2 - 4*x + 3;
display(
   plot(form, x = 1/2..4, filled, color = ["Green", "Coral"]),
   plot(f, x = 1/2..4, color = black, thickness = 2) );

You can add the allsolutions option to the call to the solve command.

Using Maple 2024.2,

Download solve_allsolutions.mw

ps. The point of the indets call is that the generated parameter name can be programmatically extracted. That can help since repeated calls to solve may generate different such names, eg. _Z3, _Z1, _Z17, etc. You can them replace it by, say, k without having to manually enter it of copy&paste. You can also target such names more specifically, eg.
     suffixed(`_Z`)`
or,
     suffixed(`_B`)

pps. It's interesting that versions Maple 2015 (or Maple 2018) and Maple 2024 can produce different valid forms. I used Maple 2024 since that is the version in which the OP's attachment was last saved.

Every new time that you utilize assume to place an assumption on a name that causes the creation of a new, separate instance of that name.

You might think of it somwhat similarly to creating a new escaped local (ie. when a procedure returns one of its locally declared names, unassigned).

Such names are distinct from each other. They are stored at distinct addresses in memory. They do not combine or cancel arithmetically.

A similar thing happens if you do the following in a single session (ie. no restart, no save&read).

1) place assumption on x. 2) assign that to f. 3) place another assumption on x using `assume` instead of `additionally`. 4) now try to use x and f together.

Yes, in your case you used the very same quality in the assumption. But that's not what's making them different. What makes them different/distinct instances of the name `x` is that they had assumptions placed at different times.

Names parsed from strings are always parsed as the global instance. So by that action both name instances become the same global name. And so those then cancel by subtraction.

ps. saving assumed or local names to .m or .mla is poor practice.

No, they are not the same.

And, no, this is not a bug in mint. The two cases are different, and documented as such.

If you don't protect against evaluation then the case using the bracketed syntax runs the risk that the globally used names (or lexically scoped names) might have been assigned values.

So, to make that case mint-clean you'd want it as,

    MmaTranslator[':-Mma'][':-LeafCount']

This aspect is discussed in the fourth bullet-point of the Description Section (and last Example) of the colondash Help-page.

So, the message by mint for your example is just as it ought to be. This is a typical situation for which that mint warning is intended; it warns you that if the higher scope name has an assigned value then your code will behave wrongly. The bug is in your code, ie. in using the unquoted global name like that.

nb. Since ideally you have to add uneval quotes and :- to the bracketed/indexed syntax, it's actually shorter and less typing to use the other form. The indexed reference is a relatively poor choice to use, in general.

Also, yes, mint is actively maintained.

If a procedure has,
   option remember, system
then its remember table items can get cleared off when garbage collection occurs.

If that's underdesirable then some entries could be made permanent instead, using say Cache:-AddPermanent.

If a procedure has just,
  option remember
then garbage collection won't clear its "classical" remember table. (A subsop(4=NULL,eval(myproc)) can still clear it off, if done manually.)

The interplay between a procedure's cache and garbage collection is discussed on the Cache Help-page. That page mentions, "The option cache is incompatible with options remember and system.", ie. a procedure cannot utilize both flavours of memoization, cache tables and "classical" remember tables. The option cache mechamism is reasonbly flexible, but a procedure that utilizes it cannot also utilize option remember, system.

[edit] The option remember mechanisms are very old. The Cache system is relatively newer (though, now, old too), intended as a more modern (organized, flexible) mechanism.

It seems that plots:-display is triggering a re-draw, and mishandling the domain merge.

A workaround, leaving color and other look&feel aspects as they were:

plots:-display(
   plot(1, x=0..1, redraw=false),
   plot(1, x=2..3, redraw=false));

This issue also appears for me in the latest Beta-testing-period development version. So I have submitted a bug report, as it appears to not be fixed yet.

ps. I'm not seeing the bug if the plotted expression is not constant, ie. if it actually depends on x.

I prefer a way that doesn't require the manual entering of multiplicative factors for cancellation.

Download solve_constants_accc.mw

a few notes:
1) Put all your assume/additonally calls at the start, before you start forming expressions involving the assumed names. Otherwise you can end up with different variables/names instances that look the same but are distinct from each other.
2) Use 2-argument eval instead of subs, to substitute methematically (rather than structurally). Even if you can get the same results here, using either. Still do it. It's a mathematically better approach in general, ie. some say, some other example.
3) Note that simplify (with no arguments) can actually undo (expand) some of the radical simplifictions that you seem to want and which you can get using combine.
4) For this example's steps of solving for G, the isolate command can be used without needing solve (and thus avoid both warnings about assumptions as well as solve's useassumptions option).

The central reason is that the ortiginal and some particular combined form don't attain the same value for all flavours of values of the parameters. The combine/simplified formula depends on the nature of the parameters (eg, their signs, or relative signs, even if taken as purely real).

Note that in your latter example, using simplify(...,[..]) ie. simplify-with-side-relations, the substitution won't happen unless the product to be replaced is actually present, and combining the relevent radicals runs into the same kinds of considerations as in your first example.

Download simplify_roots_ac.mw

You could also evaluate at various numeric values, and confirm the differences.

Sometimes, with 2D Input mode, What You See Is Not What You Get.

If I copy & paste the input (that gives your output Label (5)) then even as 2D Input the pasted entry looks different from what I copied. That I is actually parsed as a 1, even if the input doesn't look like it. If I paste it in as 1D Input then I see that the line has actually been parsed as,

    `psi__I,d` := unapply(diff(psi__1(x), x), x)

Similarly, the 2D Input on the line with your output Label (6) is actually,

    `psi__1,d`(x)

So, this is all a muddle. I don't know what you did in your Maple 2022 to get such an effect, sorry. Note that in such mysterious circumstances you can copy&paste 2D Input to a 1D Execution Group, to see what is actually going on with the parsed input.

Btw, there is a better way to do such functional differentiation, by using the D command (which was designed for just this kind of purpose). Eg,

Download psi_subscript_ac.mw