@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.)

@sursumCorda That difference in evaluation is interesting, for some versions more recent that the original Maple 2020.

When calling convert on an active (but unresolved) int call, I am used to the integration being re-attempted on the converted integrand. I'll likely look into when and why that evaluation aspect changed. It could simply have been a correction, for consistency with other convert behavior.

The following do work in my Maple 2026.1,

int(convert(arccos(x)*arcsin(x),arcsin),x);

eval(convert(int(arccos(x)*arcsin(x),x),arcsin));

int(convert(expand(convert(arccos(x)*arcsin(x),ln)),arctrig),x);

# That is, both these integrands work directly:
#  (1/2*Pi-arcsin(x))*arcsin(x)
#  1/2*arcsin(x)*Pi-arcsin(x)^2

And, of course, I agree that any forced method ought not to be needed. I believe that I subitted a bug report for this when it was first posted. I'll check my records.

@C_R The terminology on that Help page is not careful and precise. There are also some false claims. I will file a bug ticket.

This is an area where it serves to be precise, because we're throwing around technical jargon of a programming language, and ambiguity or imprecision can lead to confusion.

So, (and I offer this in the best spirit), it's not the case that `+` is "the name of a function". It's not quite right in a few different ways:
- More correct is that `+` is a name to which a procedure has been assigned.
- It's a procedure that's been assigned, not a function. (It's a good habit to strive to not use the word function to refer to a procedure/operator in a Maple context. It's too often confused with an expression. Better to reserve the word function for referencing the type function, ie. an unevaluated prcedure call.
- The same procedure can be assigned to more than one distinct name, and so it's not right to write of the name of a procedure (without qualification).

Also, I suggest that you shy away from using whattype. The type system is not hierarchical in a way for that to be a fool-proof inquiy mechanism. (I know, sorry, I've suggested this before.) Really good Library programs don't use it; they query explicitly for target types.

I realize that I'm sounding uptight here. I'm on a bit of a Documentation nit-picking kick.

Also, since we're having fun, some levity.

Quite often I find I want/need to see the static exports of an Object. For that I'd do, say,

   exports(df1, static)

If a DataFrame has 50 static exports then there's a decent chance that some collision is going to occur with a rebound name from some loaded package.  As another example, DataFrame static export Transpose and LinearAlgebra:-Transpose.  If one loads LinearAlgebra then the example Transpose(DF) breaks, but not if called as :-Transpose(DF) or DF:-Transpose(DF), etc, which is unlikely knowledge in the absence of documentation that the DataFrame DF is an Object.

But there you are... information hiding, abstraction, and hiding implementation details: key aspects of OOP, aka Principles of Object-Oriented Programming.

@C_R

Note that `+` is a name (which happens to be assigned a procedure). 

And so `+` + `+` automatically simplifies to 2*`+` , much as a+a automatically simplifies to 2*a.

By "automatically simplifies" I mean that is happens by automatic simplification, done before evaluation.  And that's not prevented by uneval-quotes, ie. 'a+a' also produces 2*a.

[edit] Here are some fun examples to study. There are two flavors of automatic simplification in the following examples:
1) name+name -> 2*name
2)  numeric * simple-poly getting the numeric coefficient distributed across the sum

More fun than a barrel of monkeys. I've written it somewhat back-to-front, in that some later examples might help explain some earlier examples.

Download auto_simp_functional_fun.mw

@C_R Your attachment cannot be downloaded since its file-name contains the special character "%".

@C_R You persist in mistakenly referring to it as if it were a single piece of self-contained syntax. Which it is not, as explained in my Answer & followup.

It's just two common syntax items used together: two different uses of parentheses, that happen to work side-by-side.