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

@nm My experiments indicate that it is not the fact that the nested procedure is anonymous that makes the difference to mint. But rather, it's the fact that the anonymous procedure is immediately, functionally applied that makes the difference to mint.

For example, I can apply an anonymous procedure using %, and mint reports as you'd expected. Or I can map an anonymous procedure across a list, say, and again mint reports as expected on the anonymous procedure. And those happen even if nested within another procedure. Eg,

foo := proc()
  local C1,y,x;
  map( proc()
         C1:= `tools/genglobal`(_C);
         sol:=y(x)=  C1;
       end proc, [ ]);
end proc:

For which my M2023.2 mint reports,

Nested Anonymous Procedure proc() on lines 3 to 6
  These global variables start with an _:  _C
  These local variables were assigned a value, but otherwise unused:  sol
  These local variables were not declared explicitly:  sol
Procedure foo() on lines 1 to 7
  These local variables were used but never assigned a value:  x, y

Apart from the aspects of whether the nested proc is assigned to some name (and what procname might produce, "unknown", etc...), I don't believe that its own behavior wrt locals, etc, differs according to whether it's anonymous or anonymous and immediately applied. Presuming that I've understood your followup points, I suspect that you're mainly just seeing a difference in what mint happens to report upon.

Your surfdata example worked properly up until Maple 2023.2. It doesn't work in Maple 2024.1.1 and 2024.2. I will submit a regression bug report.

But you can still work around that easily, by wrapping in plots:-display and passing the scaling option to that instead.

Download Scaled_matrix_plot_with_axes_ac.mw

You can use custom tickmarks for the matrixplot approach.

Download Scaled_matrix_plot_with_axes_ac2.mw

Sometimes rendering of custom end-ticks can visually clobber each other, if the values are "long", upon manual rotation. (I've reported that previously...) So generally I prefer using surfdata to using matrixplot for such examples.

As far as the implicitplot command goes, the view option is not for specifying the ranges of the curves, in the sense of what data is used to compute them. It's just for specifying the limits of the axes and how far all features may extend visually (presuming they've been constructed to extend that far).

Your four can be done in a single call to implicitplot, so I've rolled them together. I've kept the order in which you had them, which denotes how they get visually layered (ie. the green appears on top).

ps. The implicitplot command is a relatively inefficient way to construct lines, though that's not really noticeable as a one-off. So I leave it as you have chosen it.

Download The_intersection_parallelism_and_coincidence_of_two_straight_lines_ac.mw

Your code mistakenly passed gridline as an option to the Explore command, rather than the plotting command that Explore is calling. Below, gridline is passed as an option to DensityPlot itself.

The range option of DensityPlot can be used to specify the horizontal range (domain). You could utilize this to force a common range for all the parameter values. I am not sure if that aspect is what was bothering you.

Explore(Statistics:-DensityPlot(Statistics:-RandomVariable(Normal(mu, sigma)),
                                range = -2-9 .. 2+9, gridlines),
        mu = -2 .. 2, sigma = 0.5 .. 3)

I couldn't quite figure out from your Question whether you wanted the left- and right sums plotted together, or whether you wanted one sequence after the other.

Download S7_Riemann_Animation_Aire_ac.mw

You can tweak the look&feel as you wish.

Note that this overall plot is made up of several parts, each of which you can include or not. The plots:-display command combines them.

There are separate Help pages for the textplot, arrow, plot, and pointplot commands.

This is not the only way to construct something that looks like your image.

Download xa_yb_plot_ac.mw

An example is,

    -(signum(n)-1)/2

plot( -(signum(n)-1)/2, n=-10..10,
       thickness=6, size=[500,100], axes=box );

ps. Of course you could also write that as (1-signum(n))/2. 

Copy&Pasting from pretty-printed 2D Output seems like a mistake to me. Why not construct your string as you want it, and then line-print it, and then Copy&Paste from that.

You can line-print your string, intead of pretty-printing it as 2D Output.

When line-printed, the escaped backslashes are displayed as in the actual string.

You can have your procedure itself do the line-printing (in addition to returning the string). Or you can line print the result afterwards.

You can line-print using either the lprint or printf commands.

For example,

Download lineprinted_string.mw