@zenterix The purpose of the various choice for the second argument passed to the combine command is that they restrict it to only try/perform some manipulations.

If you don't pass a second argument then combine is free to do all that it can. And that's often how it gets used.

For example, combine(...,trig) will not attempt to combine radicals. And so on. It's relatively rarer that one wants to prevent certain flavors of combinings -- though of course it does come up.

Btw, your followup comment's worksheet doesn't do as much with radicals as what happens in your original worksheet. Eg, `s` and `s__2` don't have values, whereas in the original their values contain some radicals that may get combined in the subsequent steps that form the expressions assigned to `expr4` and `result`. So, while combine might not do so much of interest in your followup sheet, it does in my Answer's worksheet that addresses your original (as far as some radicals go).

You can adjust any of the lines that call combine, and do them in two steps: first create the expression (using eval or substituting or what have you), and then second apply the combine command. Then you can see the combing of radicals that occurred.

Not every construction of your expr2,expr3,expr4,result expressions need a combine call. I put some of them in only so that the progression of expressions would be more understandable and compact (if you change colons to semicolons, to see all intermediate results).

@nm Contrary to what you've just written, I was in no way suggesting a "workaround" with that mapped list example.

Rather, I was narrowing down how/when the behavior was lacking, by showing that mint is indeed sometimes able to handle a truly anonymous procedure; I showed that because you specifically asked whether it was failing because of the anonymous property. The answer to that query -- as demonstrated -- is no, it doesn't happen purely by virture of the procedure's being anonymous.

Yes, I think that mint could in principal do better with the special case of an anonymous procedure that is immediately applied, by analyzing it and producing output similar to the broader cases.

Your last comment's further justification/explanation attempt is not necessary, for me; you appear to have mistaken my understanding of the situation.

ps. A workaround might be to assign the inner procedure to a name. That could still be done in a nested manner (even though in one of you followups you didn't retain the nesting, yet you could). Note that it's more efficient to create "helper" procs just once, outside; creating the inner proc each time its's called and each time through the outer  proc is less efficient. Of course, don't know how many times you'll call it all, or whether proc creation is dwarfed by additional computations.

About your followup 2nd example, you wrote, "Also, I noticed it did not warn me that variable sol is global inside the proc."

The name sol is implicitly declared local within that anonymous procedure. Contrary to what you're written (in that direct quote), the name sol is not used as a global name in your Question's code example.

There is currently no attachment.

@Joe Riel Ignoring the mystery for now, at least this one looks legible:

restart;

kernelopts(assertlevel=2):

proc(x::coerce(set, proc(y::rtable)::set;
                      return convert(y, list);
                    end proc))
  x;
end proc(<0>);

Error, (in anonymous procedure) assertion failed, unknown expects its return value to be of type set, but computed [0]

@Joe Riel What as I missing here? I don't understand why the second of these throws the (expected) exception, while the first of them does not.

Download hmm_proc.mw

What's the end-goal here? What do you plan on doing with the result?

Is it only to get a more compact display, or do you eventually want to evaluate it at values for some/all variables and want that to be efficient?

This straightforward approach seems relatively competitive, performance-wise.

     (u->[f(op(u))])~(L)

It appears to perform better than does [`?()`]~(f,L) for large examples.

I see that the OP mentioned speed, as he had 400k+ sets of data (lists). Code being as terse as possible didn't seem a priority of the OP.

Download map_ex_perf.mw

@Aixleft math It's a good question, btw.

Historically, and up until Maple 2021, the following would produce the curve data only for x=-10..10 (default for non-trig expression, if no range is explicitly supplied),
     plot(x^2, view=[-20..20,default])
It's only as of Maple 2022 that -- in the absence of a supplied range argument -- the basic plot command utilizes the first part of the supplied view option for determining a range for computing the curve data. The implicitplot command hasn't had the same kind of tweak.

Why do you state that the problem is due to remembered/cached computations? How do you know for sure that is the problem?

There are other (albeit relatively rare) mechanisms that can cause ordering differences and other seemingly random effects. It might well be that some cached results are the cause, but how are you so sure of it?

Please provide an example that explicitly illustrates the proplem, with full code-to-reproduce (either all necessary text code, or a worksheet attached with Mapleprimes' editor's green up-arrow).

It sounds as if you might be using plots:-textplot twice, separately for each of letter and subscript. Is that what you're doing? If so, why do you not use the usual mechanisms which render subscripts in 2D Output? Eg, an indexed name such as x[i] or a double-underscore such as x__i

plots:-display(
  plots:-textplot([1,2,x[i]], font=[Times,20]),
  plots:-textplot([1,1.25,x__i], font=[Times,20]),
  view=1..2.2, size=[200,200]);

@mmcdara The first of your two ways seems to have problems, since Maple 2017.3 (at least).

The second way works, except that I don't (as yet) see how gridlines could be added easily, or a common t-range be used for all parameter choices. If I'm not mistaken, these are some of what the OP asked.

@nm I don't understand why you wouldn't provide the example that reproduces the issue, if you already had it at hand when you originally posted.

I have a recollection of this happening for someone else recently. (Rouben R., perhaps)

IIRC, the cause seemed to be with a worksheet that had Vector/Matrix output, that was saved to .mw in Maple 2024.2.

Resaving in Maple 2023.2 (or, maybe, 2024.0...) removed the problem.

My guess was that it was something to do with new scrollable rtable display; something in the .mw tjat the Mapleprimes backend .mw renderer baulked at.

I didn't confirm exact detail by rigorous experimentation.

The following image is a screenshot from my Maple 2024.2 for Linux (ubuntu).

I have no Maple init file or style sheet in play.

The numerals in the above screenshot image appear exactly as they do in 2D Input in that session.

The Maple GUI's toolbar indicates that the font is DejaVu Serif.

That is the default for modern Maple on Linux, AFAIK.