There are no files attached to your Question. Please try attaching them again.

@Joe Riel It's frustrating that the expository section of help page ?object,create has 8 paragraphs devoted to "Inheritance", but the "Examples" section doesn't have a single example of it.

@sursumCorda The specific example that you show can be done by

M:= <4, 1, 1 | 0, 5, 2 | 7, 8, 9>:
<sort(convert(M, list, dimension= 1), key= (R-> [seq](R[[1,3,2]])))[]>;

Higher dimensions can also be accomodated.

@Mike Mc Dermott Okay, here's an example verifying real-time enhancement on both integer and hardware-float data:

nV:= 6:  V:= [x||(1..nV)]:
P0:= codegen:-makeproc(randpoly(V, dense, degree= nV), V):
P1:= codegen:-optimize(P0):
P2:= codegen:-optimize(P0, tryhard):
(lprint@codegen:-cost)~([P0, P1, P2]):
918*additions+4727*multiplications
221*storage+221*assignments+1827*multiplications+918*additions
108*storage+108*assignments+855*multiplications+917*additions

DataInt:= 
    'rtable(1..2^13, random(-9..9), datatype= integer[4], subtype= Vector[row])' 
    $ nV
:
for k from 0 to 2 do gc(); R[k]:= CodeTools:-Usage((P||k)~(DataInt)) od:
memory used=375.70MiB, alloc change=0 bytes, 
cpu time=1.95s, real time=1.96s, gc time=0ns

memory used=72.91MiB, alloc change=0 bytes, 
cpu time=844.00ms, real time=847.00ms, gc time=0ns

memory used=39.18MiB, alloc change=0 bytes, 
cpu time=469.00ms, real time=473.00ms, gc time=0ns

#Verify accuracy:
LinearAlgebra:-Norm~([R[0]-R[1], R[1]-R[2], R[0]-R[2]], infinity);
                           [0, 0, 0]
DataHF:=
    'rtable(1..2^13, frandom(-2..2), datatype= hfloat, subtype= Vector[row])' 
    $ nV
:
for k from 0 to 2 do gc(); R[k]:= CodeTools:-Usage((P||k)~(DataHF)) od:
memory used=404.77MiB, alloc change=0 bytes, 
cpu time=7.02s, real time=4.07s, gc time=3.53s

memory used=195.47MiB, alloc change=0 bytes, 
cpu time=1.38s, real time=1.38s, gc time=0ns

memory used=92.04MiB, alloc change=0 bytes,
cpu time=563.00ms, real time=558.00ms, gc time=0ns

#Verify accuracy:
(lprint@LinearAlgebra:-Norm)~([R[0]-R[1], R[1]-R[2], R[0]-R[2]], infinity):
.123691279441118240e-9
.436557456851005554e-10
.130967237055301666e-9

I was rushed when I wrote the Answer above. Here's a more-complete example:

Statistics:-ColumnGraph(
    [1,2,3,4], #column heights
    width= 2, distance= 1,
    axis[1]= [
        tickmarks= [
            [seq](k+1 = sprintf("%a - %a", k, k+2), k= 0..11, 3), 
            rotation= Pi/4
        ]
    ],
    axesfont= ["Arial", 18]
);

@2cUniverse You can never make a valid comparison between two measurements both of which have been rounded down to 0. You must either use a finer measuring instrument, or increase the scale of the problem until the instrument returns positive values. The latter is usually easier in Maple.

iremFrac2a:=proc(n,d, b)
   local r1,r,i,li:
   li:=NULL:
   r:= irem(n*b,d):
   if NumberTheory:-AreCoprime(d,b) then
     while true do
        r1:= irem(b*r,d):
        li:=li,[[r,r],[r,r1]],[[r,r1],[r1,r1]]:
        if r1=n then break fi:
        r:=r1:
     end do:
   else print("Denom-Base not coprime "): return [] fi:
   [li]
end proc
:   
iremFrac2b:= proc(n, d, b) local N:= irem(n,d), r:= irem(N*b, d), s; 
    [if igcd(b,d) = 1 then 
        (do [[r,r], [r, (s:= irem(b*r, d))]], [[r,s], [s,s]] until (r:= s)=N)
    else
        print("Denom-Base not coprime")
    fi]
end proc
:
d:= nextprime(2^17):  b:= irem(rand(), d);
                          b := 116956

(L1, CT1, RT1):= CodeTools:-Usage(
    iremFrac2a(1, d, b), output= [output, cputime, realtime]
)[]:
memory used=14.24GiB, alloc change=-32.00MiB, 
cpu time=5.09m, real time=79.49s, gc time=4.93m

(L2, CT2, RT2):= CodeTools:-Usage(
    iremFrac2b(1, d, b), output= [output, cputime, realtime]
)[]:
memory used=14.89MiB, alloc change=0 bytes, 
cpu time=172.00ms, real time=165.00ms, gc time=0ns

#Verify that computed results are equal:
evalb(L1 = L2);
                              true

#time ratios (real and CPU):
RT1/RT2, CT1/CT2;
                    481.7333333, 1776.529070

To be fair, those ratios are not as extreme if I increase the scale of the problem "horizontally" (i.e., smaller test cases but more of them) rather than "vertically" (i.e., a single large test case), as above. I'll explain why in a moment.

d:= nextprime(2^10):  b:= irem~(['rand()'$64], d);
b := [173, 917, 905, 706, 476, 906, 759, 1001, 827, 720, 297, 35, 
  933, 582, 61, 289, 139, 245, 817, 496, 11, 477, 1001, 541, 824, 
  911, 787, 901, 990, 853, 562, 160, 248, 313, 631, 873, 630, 
  281, 565, 282, 85, 761, 311, 1021, 475, 123, 593, 632, 209, 
  683, 931, 296, 348, 381, 890, 772, 720, 565, 529, 277, 861, 
  286, 147, 912]

(L1, CT1, RT1):= CodeTools:-Usage(
    iremFrac2a~(1, d, b), output= [output, cputime, realtime]
)[]:
memory used=283.35MiB, alloc change=8.00KiB,
cpu time=6.34s, real time=1.70s, gc time=6.02s

(L2, CT2, RT2):= CodeTools:-Usage(
    iremFrac2b~(1, d, b), output= [output, cputime, realtime]
)[]:
memory used=13.95MiB, alloc change=0 bytes,
cpu time=172.00ms, real time=172.00ms, gc time=0ns

#Verify that computed results are equal:
evalb(L1 = L2);
                              true

#time ratios (real and CPU):
RT1/RT2, CT1/CT2;
                    9.877906977, 36.88372093

The reason is that when you create a sequence (or list or set) by appending to an existing sequence, each assignment reconstructs the entire sequence. Of course, the time for each such reconstruction is proportional to the length of the sequence. Thus, the time for the whole loop (just for this reconstruction minutiae, not for the actual desired computation) is proportional to the square of the number of loop iterations. Using the standard asymtotic-order ("big O") notation, we say that the time for this process is O(n^2) (where n is the number of iterations).  Assuming that the actual computation time for each sequence element is independent of its position in the sequence (which is very often the case, and it's certainly true in this case), that time is O(n) in total. It's mathematically certain that there's a value of n, say n_c, such that the O(n^2) process will dominate the O(n) process for all n > n_c. In more-technical mathematical language, for any A > 0, B > 0,

limit(A*n^2 / (B*n) , n= infinity) = infinity.

@2cUniverse Your new version can be coded like this:

iremFrac2:= proc(n, d, b) local N:= irem(n,d), r:= irem(N*b, d), s; 
    [if igcd(b,d) = 1 then 
        (do [[r,r], [r, (s:= irem(b*r, d))]], [[r,s], [s,s]] until (r:= s)=N)
    else
        print("Denom-Base not coprime")
    fi]
end proc
:

The N:= irem(n,d) is needed because if n >= d then the loop will never reach n.

Oh, I just realized that this may have not been obvious before: The number of loop iterations is always MutiplicativeOrder(b,d), but dividing that number by two isn't always relevant.

@sursumCorda GMP is open source and publically licensed. You can find numerous websites with documentation of the whole package or of invidual components such as "GMP isprime". The Maple help page ?GMP contains a link to the source code as it's been modified for use in Maple.

@Mike Mc Dermott Your example is too small for a difference to be shown. For any expression of practical size for which I've used optimize(..., tryhard) over the past 20 years, it has made a great improvement in the optimization. The extra time taken by the optimizer has always been trivial compared to the improvement in execution time. Here's an example:
 

Download OptimizeTryhard.mw

@sursumCorda That's a good find on your part. Here are the new timings using option compile on all Iterators, and running twice so that the compilation time isn't counted.

LL:= [seq]([$0..k], k= 1..8): #So, product has 9! 8-tuples.
for k to 6 do cp[k]:= CodeTools:-Usage(CP[k](LL)) od:
combinat:-cartprod:
memory used=189.79MiB, alloc change=0 bytes,
cpu time=2.66s, real time=2.15s, gc time=703.12ms

Iterator:-CartesianProduct:
memory used=173.28MiB, alloc change=5.64MiB, 
cpu time=2.66s, real time=2.09s, gc time=796.88ms

Iterator:-MixedRadixTuples:
memory used=106.80MiB, alloc change=2.87MiB, 
cpu time=2.56s, real time=2.29s, gc time=390.62ms

Iterator:-MixedRadixGrayCode:
memory used=106.80MiB, alloc change=0 bytes, 
cpu time=2.69s, real time=2.36s, gc time=421.88ms

Iterator:-MultiSeq:
memory used=386.46MiB, alloc change=0 bytes,
cpu time=4.70s, real time=3.46s, gc time=1.72s

Carl's own cartesian product iterator:
memory used=138.49MiB, alloc change=-8.50MiB,
cpu time=1.89s, real time=1.62s, gc time=359.38ms

@2cUniverse My ideas regarding remainder -1 weren't intended for all moduli. 97 is prime; 49136 is not. The idea will work for moduli of the forms p^k and 2*p^k for odd primes p. If the remainder -1 occurs, then it corresponds to d-1 and is obviously the maximum of the list. But for a highly composite modulus such as 49136, it's unlikely that -1 will occur as a remainder for some arbitrary base b.

Your procedure remainders is very inefficient because it builds a sequence by appending, and it also has a few other much-more-minor inefficiencies. Here's an improvement:

remainders:= proc(n, d, b) local n1:= irem(n,d), r:= n1; 
    `if`(igcd(b,d) = 1, [r, (do r:= irem(b*r, d) until r=n1)][..-2], FAIL)   
end proc:

The remainder 1 is usuallly put at the end of the list R and not the beginning, so that R[k] = b^k mod d. If you do it that way, the procedure can be simplified to

remainders:= proc(n, d, b) local n1:= irem(n,d), r:= n1; 
    `if`(igcd(b,d) = 1, [do r:= irem(b*r, d) until r=n1], FAIL)   
end proc:

@sursumCorda To my great surprise, combinat:-cartprod is the best of those 5, and Iterator:-CartesianProduct is by far the worst. (My timings below do not include the once-per-session compilation times for the Iterators.) To celebrate, I rewrote combinat:-cartprod and made a significant improvement in its time. Another difference among the methods is that they give the results in different orders.

Using my new CartProd iterator, I reduced the time for A161786__2(10^6, 10^6) to under 6 seconds and the time for A161786__2(1, 2*10^6) to under 7 seconds!

restart
:
CP[1]:= LL-> local nx:= combinat:-cartprod(LL)['nextvalue'];
    {to mul(nops~(LL)) do nx() od}
:
CP[2]:= LL-> local c;
    {for c in Iterator:-CartesianProduct(LL[]) do [seq](c) od}
:
CP[3]:= LL-> local c, k, j;
    {for c in Iterator:-MixedRadixTuples(nops~(LL)) do 
        [for k,j in c do LL[k][j+1] od]
    od}
:
CP[4]:= LL-> local c, k, j;
    {for c in Iterator:-MixedRadixGrayCode(nops~(LL)) do 
        [for k,j in c do LL[k][j+1] od]
    od}
:
CP[5]:= LL-> local c, k, j;
    {for c in Iterator:-MultiSeq(<[1$nops(LL)]>..<nops~(LL)>) do
        `?[]`~(LL, [seq](`[]`~(c)))
    od}
: 
#My improvement of combinat:-cartprod:
CartProd:= proc(LL::list({list, set})) 
option `Author: Carl Love <carl.j.love@gmail.com> 2023-Oct-24`;
local 
    n:= nops(LL), N:= nops~(LL), J:= rtable([1$n-1, 0], datatype= integer[4]),
    M:= rtable((1..n, 1..max(N)), [op]~(LL))
;
    proc() local i:= n, j;
        while J[i] = N[i] do J[i--]:= 1 od;
        J[i]++;
        [for i,j in J do M[i,j] od]
    end proc,
    mul(N)
end proc
:
CP[6]:= proc(LL) local (nx, N):= CartProd(LL);
    {to N do nx() od}
end proc
:
LL:= [seq]([$0..k], k= 1..8):

#I actually ran these tests twice after the restart 
#so that the Iterators would be compiled:
for k to 6 do cp[k]:= CodeTools:-Usage(CP[k](LL)) od:
memory used=189.79MiB, alloc change=2.77MiB,
cpu time=1.89s, real time=1.89s, gc time=0ns

memory used=407.77MiB, alloc change=5.64MiB,
cpu time=3.53s, real time=3.54s, gc time=0ns

memory used=106.80MiB, alloc change=2.87MiB, 
cpu time=3.25s, real time=2.37s, gc time=1.03s

memory used=106.80MiB, alloc change=5.64MiB,
cpu time=2.16s, real time=2.16s, gc time=0ns

memory used=386.45MiB, alloc change=5.64MiB, 
cpu time=2.92s, real time=2.93s, gc time=0ns

memory used=140.25MiB, alloc change=-19.78MiB,
cpu time=2.67s, real time=1.68s, gc time=1.17s

nops({entries}(cp, nolist));  #Show that all results are the same
                               1

Your worksheet shows two procedures for this---one named rho and one named InversePtMobius. Since those two procedures obviously give identical results, I don't understand what exactly you're asking.

@2cUniverse Since it's obvious that your list is the powers of 2 modulo 97, here are two more methods based on that:

NumberTheory:-ModularLog(-1, 2, 97);

NumberTheory:-MultiplicativeOrder(2, 97)/2;

Both of these return 24. You were getting 25 because you started your list at 2^0 rather than 2^1. The MultiplicativeOrder is likely more efficient because it makes use of the special status of -1 as the primitive square root of 1. The 2 in the denominator is to get the logarithm of -1, and it's independent of the base, 2, or the modulus, 97.  

I think that in your first line, you tried to enter a formula for h, but it got replaced by characters that look like rectangles with Xs in them.