@Bendesarts My style for that would be

MAINPACKAGE:= module()
local XM:= 1;
export
    ZM:= 3,
    SUBPACKAGE1:= module()
    local X1:= XM;
    export Z1:= ZM;
    end module
;
    :-YM:= 2
end module
:

That is, to whatever extent that it's possible, a meaningful assignment should be made to a variable at the point that it's declared local or export. If nothing meaningful can be assigned, then leave it blank.

@Bendesarts There are two small errors in your posted code. The first is that ZM:= 3 needs to end with a semicolon (or colon). The second is that all named entities, including modules and procedures, should be declared either local or export.

@MapleEnthusiast

You can verify that your technique is correct by applying it to a numeric stochastic matrix.

If I replace LeastSquares with LinearSolve (no other changes are needed), then I get the solution for your new P in a quarter second.

@mmcdara Thank you for the vote up.

I'd like to address the "tricky accounting" mentioned by the OP in this remark:

• note that there are often multiple copies of the least unused term, which might make accounting for them tricky. 

The way that I addressed this is to store the indices, not the entries, in the heap. The entries determine the order of the heap, but they are not in the heap.

The elegance would be enhanced a bit if Maplesoft updated the old-style table-based object heap to a modern module-based object. This would be an easy job for an intern.

@Sradharam Your derivative notation is very unusual, and I don't understand it. Would you please post the equation(s) in a more standard form?

@Dark Energy The phase planes in the worksheet that you linked are specific to systems of autonomous first-order ODEs. Your functions are neither ODEs nor autonomous. 

@Earl I had already noticed the missing colon and had fixed it. The memory use that I reported is for the GUI alone, not for the kernel, and that number is only visible through Windows Task Manager or a similar external application; you can't see it on the status bar or through any Maple command (that I'm aware of). This may be a Maple 2021 bug. I've already noticed that the rendered versions of 3D plots displayed in Maple 2021's GUI are much larger than those for Maple 2020. (This has nothing to do with the number of points computed via, say, the grid option to plot3d; it only affects the rendering.) The fact that I have a QHD display may have something to do with this.

@nm I think that what you said is only partially true. The evidence that it's not completely true is the large number of options that pdsolve has by which one can guide it towards a solution and control the "completeness" of the solution.

@Earl The plot in your worksheet is much too big for my computer to handle. The GUI alone consumed 13 Gig of memory, and I needed to kill my entire Maple session.

However, I can see from your code that you are using a coloring technique completely different from what I described.

@acer I agree in general with all that you said. However, you might not realize that my only purpose (and I'm guessing VV's only purpose) was to read (as a human) the code of partition1 out of mathematical interest. I wasn't trying to extract the code to execute it. I think that both of our methods are useful for just reading the code.

Whenever I'm on a code-reading exploration like that, I habitually set verboseproc to 2 or 3 and opaquemodules to false (whether it ends up being needed or not).

My comment about browsing the library was meant to be a remark on the difficulties one faces when trying to read the library (just as a human reader, not for execution purposes). I didn't mean to suggest that some large percentage of those numeric-name-only entries were similar to partition1.

By the way, why is the library mentioned specifically in that bit of the Inert tree that I extracted?

I guess that you're avoiding piecewise because you can use neither it nor Heaviside in off-the-shelf Fortran?

@vv Here's another way to get to the code of that procedure:

interface(verboseproc= 3):
kernelopts(opaquemodules= false): #not strictly needed in this case
indets(
    ToInert(eval(combinat:-partition)),
    And(
        specfunc(_Inert_ASSIGNEDLOCALNAME), 
        satisfies(x-> op(1,x)="partition1")
    )
);
{_Inert_ASSIGNEDLOCALNAME("partition1", "PROC", 
  36893490238314748452, _Inert_ATTRIBUTE(_Inert_STRING("C:\Progr\
  am Files\Maple 2021\lib\maple.mla")))}

P:= pointto(op([1,3], %));
                        P := partition1

eval(P);

Browsing through the main library with LibraryTools, I chagrinfully note that the vast majority (about 90%) of entries are anonymous, with their only "name" being an integer of 5 or 6 digits.

@vv If you replace option autocompile with option remember, then for the largest of the cases that you showed, the *non*-compiled procedure is 169 times faster than the compiled procedure.

@tomleslie I've seen that problem also in Maple 2021. For me, it didn't occur with this worksheet. I suspect that this bug has nothing to do with one's code and instead is based on environment 

@Preben Alsholm As far as I can see, it works in Maple 2021. Which part isn't working for you?