I have seen a report of it working in M2025 and M2026 on Windows 11.

@GFY I see now. Somehow I'd got the impression that there might be some other, more involved example.

Yes, this is a key purpose of IntegrationTools:-Expand, which is why I mentioned it in my Answer.

Your example-at-hand shows that I may have been too worried about unwanted extra expansion of subterms in the integrand. I was considering an unfortunate example such as,

    goo := Int( (1-cos(t)^2)*(1-sin(2*x)^2), x=a..b );
    IntegrationTools:-Expand(goo);

But if that kind of thing isn't causing you problems, then all the better.

ps. In your last Reply you seem to be using the word "summation" to refer to an explicit, finite sum of terms, ie. the result of explicitly adding a concrete, finite number of terms. That is not a good use of that word, especially since in your original Question you used around Sigma notation  and a name n as upper end-point, for your query 1).

You wrote, "...using Expand does indeed make it possible to transform the inert integral of a summation into a summation of inert integrals."  But that's not true at all. Transforming an integral of a summation into a summation of integrals is the topic of your other query 1). The Expand command makes it possible to transform an integral of an explicit sum of terms into an explicit sum of integrals.

@GFY You haven't supplied your more complicated, explicit examples, so it's difficult to be sure about what difficulties you might have had with part 2.

It's not clear to me whether you are starting with the integrand in a state that is factored into f(t) and g(x) multiplicands, and whether the stock command attempts were just muddying up the integrand too much for easy recovery.

It's quite possible that a dedicated routine would be much better, once in f(t)*g(x) form. I mean, that could be a reusable, short proc -- something nice in an init file. Would that be useful?

@GFY He has used a Code Edit Region.

This is a link to its Help page in a more recent version than your Maple 2022.

In your version your can access its Help page by query for Topic CodeEditRegion,

@emendes 

I realize that there were already comments that described that proc as being less efficient. But I don't understand the point of showing something flawed in ways that can be remedied. (That's a bit like a straw man...)

Also, another variant given by janhardo in the same Reply contains,

   [seq(seq(subsop(i = model[i] + t, model), t = convert(missing[i], list)), i = 1..n)];

but that lacks a check on whether missing[i] is of type `+`. If it's not, and if it's a single product term, then conversion to a list will produce the wrong result. That's a bug in the code.

Also, not all of these variants seem to give the same results for your example problem.

Parts of the revision shown by janhardo is inefficient. It illustrates a classic programming problem.

I have seen AI generated code (reposted by janhardo), make this mistake before, in other postings.

result := [op(result),
           subsop(i = model[i] + t, model)];

One of the problems with repeatedly augmenting a list in this manner is that it's unnecessarily of a higher computational complexity (in memory). It can scale up unnecessarily poorly in consequence.

A technique of instead adding new items into a table, and then producing a list from that as a final step, is often better. (Note that was done in the OP's earlier version.)

Using another data-structure might be faster, and doing less additional work (than the original) might be faster. But that revision by janhardo likely doesn't scale up as well as it might do, because it's falling afoul of O(n^2) instead of O(n) memory use for assembling some results (and ensuing memory management cost) unneceassarily.

@sand15 Using Maple 2015.2, I was able to "see" that the conditional block of the original code, in,

   showstat(`plots/sparsematrixplot`,4..8);

corresponded to this portion of the inert representation of that original procedure,

   op([5,3],ToInert(eval(`plots/sparsematrixplot`)));

I also noticed that the fragment of that inert code,

   _Inert_STATSEQ(_Inert_ASSIGN(_Inert_LOCAL(8), _Inert_FLOAT(_Inert_INTPOS(0), _Inert_INTPOS(0))))

corresponds to the assignment,

    delta := 0.

So I used subsop to replace the conditional block with itself followed by that simple assignment.

I suppose that it'd be simpler merely to replace that conditional block altogether, by that simple assignment. Ie, in Maple 2015.2,

restart;
`plots/sparsematrixplot` := 
   FromInert(subsop([5,3]=_Inert_STATSEQ(_Inert_ASSIGN(_Inert_LOCAL(8),
                                                      _Inert_FLOAT(_Inert_INTPOS(0),
                                                                   _Inert_INTPOS(0)))),
                    ToInert(eval(`plots/sparsematrixplot`)))):

showstat(`plots/sparsematrixplot`);

One can ascertain that delta is the 8th local of the original procedure. The following is one way to figure out that the inert form of the desired new simple assignment has to be done to _Inert_LOCAL(8) .

restart;

# local sequence of the procedure
op([2],ToInert(eval(`plots/sparsematrixplot`)));

      _Inert_LOCALSEQ(_Inert_NAME("i"), _Inert_NAME("j"), 
      _Inert_NAME("m"), _Inert_NAME("n"), 
      _Inert_NAME("otherOptions"), _Inert_NAME("poly"), 
      _Inert_NAME("polygons"), _Inert_NAME("delta"))

# delta is the 8th local
op(8,%);
                      _Inert_NAME("delta")

The fact that the assignment delta:=0. happens to already occur in the original code means that there's an even terser variant (which can only be done once per session, because it clobbers the original procedure). It's luck that one could also do it this way:

restart;
`plots/sparsematrixplot` := 
   FromInert(subsop([5,3]=op([5,3,4],ToInert(eval(`plots/sparsematrixplot`))),
                    ToInert(eval(`plots/sparsematrixplot`)))):
showstat(`plots/sparsematrixplot`);

These kinds of manipulation looks complicated, but if you manipulate inert representations of procedures often enough it gets easier.

Naturally, it gets much more involved if one wants to check that a target-to-replace exists as one expects. One can guard against mistakes by wrapping in checks of the Maple version number, or testing that the block to replace is of the expected form, etc.

I could mention that if this kind of manipulation gets too involved then (as long as the proc doesn't reference some module's non-exports) one might as well print the proc, copy, and edit the new version as desired.

@awass 

It might be faster if you also changed your h like so,

h:=proc(k,x) option remember;
  local z,w;
  nans(parameters=[k,x]);
  z:=nans(0.98);
  w:=rhs(z[2]),rhs(z[3])
end proc;

I'm glad that you got at least one way to work.

note that, in my other way,
    plot([ x->h(7.7,x)[1], x->h(7.7,x)[2], 0..30 ]);
the last entry of the list is 0..30 ie. a plain range, and no longer x=0..30 ie. of type name=range. I'm not sure if you copied literally or whether that might have tripped up you attempt. If not, it's be difficult to say more without the full code of your example.

@dharr Note that the OP is attempting to use a parametric calling sequence of the plot command. And that expects two items in the list, before the name=range.

If you merely delay the evaluation of h(7.7,x)  (eg. by your way, or by simply wrapping in single-quotes) then plot won't see a pair, and it won't receive valid input.

It'd be similar to this:

f:=proc(x,y)
 if not [x,y]::[numeric,numeric] then return 'procname'(_passed) end if;
 cos(x),sin(x*y) 
end proc:

plot([f(x,7.7),x=0..3]);
Error, (in plot) incorrect first argument [f(x,7.7), x = 0 .. 3]

I will submit a bug report against this regression in behavior in Maple 2026.

It seems to me that the problem might occur only if the filled (or filledregion) option is supplied.

In the meantime I'll note that the orientation can be otherwise specified in a wrapping call to plots:-display. Apologies if you were already aware of that, and naturally there's still a bug. Eg.

with(plots):

display(contourplot3d(-x/(x^2+y^2+1),x=-3..3,y=-3..3,filled),
        orientation=[90,45,45]);

What don't you simply put all your very recent and highly related Posts on this into one single Post?

Five Posts with closely related prime number code in them, in less that 48 hours, seems a bit like spam. I've deleted several of them.

If you want to add the contents of the others to this one Post here, and followups, please go ahead.

@C_R The `Compare` procedure's special evaluation rules, ie. VV::uneval for its second argument, combined with the special way Equation Labels are handled (so they don't prematurely evaluate, say), is producing an effect that you don't like.

Contrasting with the behavior that happens when you pass the input, literally, isn't a very sensible comparison, in light of that.

Conflating proc parameter specifier ::uneval and constructor uneval(...) isn't very helpful here, as they are not identical.

See also my previous comments about Equation Label evaluation quirks.

You have been shown three working approaches, including the documented one(!) of passing Compare the extra option. See my Answer.

If you feel that there's a GUI/kernel bug, you should submit a report.

@C_R I don't see any evidence that what was happening was that the kernel didn't know to which output you referred.

I do see confusion about evaluation concepts, in what was attempted in your worksheet, etc.

Equation Labels have some evaluation quirks, partly due to the GUI/kernel/Typesetting-parser trying to get them to behave like literal input (or as close to that as possible). It seems difficult to get it quirk-free, and their behavior in some circumstances has change slightly ovet the years, as buggy cases have been adjusted.

@C_R If you call   uneval((2)[1])   for your Expression Label  (2)  then the indexing selection evaluates up front.

Perhaps you wanted  uneval((2))[1]  , which would apply the quotes, and then the indexing.

Using an expression sequence assigned to a name,

foo:=a,b: uneval(foo)[1];

              'a, b'[1]

@dharr It works now because I fixed the link. (Originally, if was a local link like file:::/... ie. a link to a local file on the responder's machine. I replaced that with an arxiv.org URL I located.)