I realized that compiled code recognizes parity checks (::odd, ::even), and by using these as a replacement for mod 2, I reduced the total time to 7 seconds. Again, that's the total time using a single processor. It should be possible to parallelize this (e.g., rowwise), but I have yet to get it to work with Threads.

I also added comments that explain the arithmetic.

restart
:
BuildA_M:= proc(
    A::Array(datatype= integer[4]), M::Array(datatype= integer[4]),
    r::integer[4]
)::integer[2];
local 
    i0::integer[2], i::integer[2], j0::integer[2], j::integer[2],
    m::integer[2], t0::integer[2], t::integer[2],
    p::integer[2], #parity (1=even, 0=odd) of 1 bits in a word
    Z::integer[2] #count of 0s
;
    for i0 to r do for j0 to r do
        Z:= 0; 
        for t0 to r do
            p:= 1; i:= i0-1; j:= j0-1; t:= t0-1; m:= M[t0];
            while i*t <> -j*m do #i.e., while they're not both 0
                #The effect on the low-order bit of the operation i*t-j*m is
                #equivalent to that of the operation Xor(And(i,t), And(j,m)).         
                if (i*t - j*m)::odd then #low bit = 1
                    p:= 1-p #Switch parity of count of 1-bits. 
                fi;
                i:= i/2; t:= t/2; m:= m/2; j:= j/2 #integer divisions!
            od;
            if p=1 then Z:= Z+1 fi
        od;
        A[i0,j0]:= Z
    od od;
    0
end proc
:
BuildA:= Compiler:-Compile(BuildA_M):

LArip:= proc(n::posint)
local 
    r:= 2^n, 
    M:= Array(1..r, combinat:-randperm(r) -~ 1, datatype= integer[4]),
    A:= Array((1..r)$2, datatype= integer[4])      
;
    BuildA(A, M, r);
    (A, M)  
end proc 
:
(A,M):= CodeTools:-Usage(LArip(8));
memory used=287.77KiB, alloc change=0 bytes, 
cpu time=7.06s, real time=7.07s, gc time=0ns

@Carl Love My code above can handle your longer example just as well:

str:= "A": s1:= " some very long string here":
s2:= " it was%s 10 ": s3:= "another very long string": 
x:= 10:
str:= sprintf(cat(str, s||(1..3)), if x++=10 then "" else x:=9; " not" fi);
x;
  str := "A some very long string here it was 10 another very 
     long string"

                               11

@nm Appending [] to a list or set returns the underlying sequence, just like op. Unlike op, this only works for lists and sets. I know that I've seen this in the help somewhere. 

It's sometimes useful to append [] to an rtable. This is a completely different usage, somewhat akin to eval, and the end result is still an rtable.

@mmcdara You've done a good job learning to use evalindets / subsindets in 1-2 days.

I'm not sure what you're asking for. The curve that you're plotting is a polynomial. Polynomials don't have asymptotes. So, do you want to modify your function so that it's not a polynomial?

@mmcdara You wrote:

• you need to use 1@@0 here because you want to add legends to a list of "PLOT structure" in a single shot.

Hmm, after a few moments thought, yes, that's totally true. The reason I hesitated though is that thinking about it like that does not occur to me while I'm coding a "surgery" such as this: My mental focus is entirely on what needs to be changed, not on what needs to remain unchanged such as the PLOT(...).

My 1@@0 could be replaced by c-> (c, _rest). Then it'd be fairly close to what you had, and probably just as efficient.

@Zeineb As mentioned by VV in another thread, you should probably change the procedure header. In particular, the algebraic is not doing you any good, and it may even be a problem in some cases not yet seen. I suggest this header:

proc(
   f::procedure, a::realcons, b::realcons, N::And(posint, Not(1)),
   {print_table::truefalse:= false, print_err::truefalse:= false}
)

@Zeineb I said tab_err:= Vector.... You have tab_err:= array....

@DarkMath To me, a true functional is something akin to Maple's D command: It takes a procedure (function) as its argument and returns a procedure. It's easy to do the same thing with your integrals. Then you could do away with the need to pass in the r and pass in the shift.

f:= g-> 
    local _r, r; 
    subs(__R= intat(g(_r), _r= __r), __r= r, __r-> __R)
:
f(sin);
       r-> -cos(r) 

f(sin)(r);
                            -cos(r)

f(sin)(r+eps);
                         -cos(r + eps)

@mmcdara 1@@0 evaluates to ()-> args. The 1 could be replaced by almost anything and it'd still work; the 1 just seems appropriate. The zeroeth iterated power of any function is the (multi-argument) identity function. 1 (or any number) can be considered a function in Maple that returns itself. Note that (f@@2)(x) returns f(f(x)) and generalize from there.

If that's not sufficient explanation, just ask again.

@abdulganiy The ability of display to handle legend must've changed recently. Here's a version of Tom's plot that should work for you:

restart:
B:= [
    [ 
        600*2^~[$0..4]+~1,    
        [2.87E-19, 7.94E-21, 7.94E-23, 1.03E-24, 5.91E-26]
    ],
    [
        2000*2^~[$0..4]+~1, 
        [3.30E-2, 5.37E-4, 8.47E-6, 1.33E-7, 2.08E-9]
    ],
    [
        [183, 365, 728, 1476, 2910],      
        [4.58E0, 7.54E-8, 2.20E-11, 4.95E-14, 9.15E-15]
    ],
    [
        [1621, 3020, 6166, 12022],      
        [2.95E-3, 8.51E-6, 3.39E-8, 2.51E-10]
    ]
]:
plot(
    (`[]`~@op@(log[10]~)~)~(B),
    legend= ["BFFM", "BNM", "BHM", "ARKN"],
    color= [red, gold, blue, black],
    symbolsize= 15,
    axes= framed, 
    symbol= [box, circle, solidbox, solidcircle],
    style= "pointline",
    labels= (typeset@log__10)~([NFE, `Max Err`])
);

@Jean-Michel Collard 

I have considered everything that you've posted to be appropriate material for MaplePrimes. However, you consistently (well over half the time) put your contributions in the wrong places. When I have suggested to you the correct placement (without any tone of reprimand), you have responded with stubborness and refusal. I would call that "roughness".

This is not a "chat room". It's a repository of technical and scientific information whose contributions will be used for reference for many years to come. Correct placement of the material helps with that.

@Carl Love And here is how you would correct the syntax on what you were trying to do. But note that this is not the preferred way to integrate a numeric ODE solution:

g:= 9.81:  h:= 0.1:  rinit:= 0.1: tinit:= 5:
dsysA:= {
    diff(r(s), s) = sqrt((g*r(s) + h)^2 - 1 + 1/r(s)),
    r(0) = rinit
}:
dsnA:= dsolve(dsysA, numeric, abserr= 1e-6):
rA:= s-> `if`(s::numeric, eval(r(:-s), dsnA(s)), 'procname'(args)):
rA(0.1);
                       0.429604957845729

t:= s-> tinit + 
    int(p-> (g*rA(p) + h)/(1 - 1/rA(p)), 0..s, numeric, epsilon= 1e-6)
:
t(0.1);
                        4.89144148361160

@Jean-Michel Collard I don't have direct access to users' email addresses. But any user here can contact another user via email by using the More => Contact Author menu in the bottom right corner of any message. I just used this method to send you one, which you can reply to via normal email.

If you send me an email, there's a good chance that I'll do one of these things:

1. Say that the material should be discussed on MaplePrimes.
2. Edit the material such that it'd be appropriate for MaplePrimes and return it to you so that you can post it.
3. Edit the material, return it, and suggest that I post it.

As the second-highest-ranking Moderator here, I request that you respect my decision on what material is appropriate for MaplePrimes and whether it should be added to an existing thread or made into a new thread.

@tomleslie My guess is that those two numbers were deemed outliers and not wanted for this plot.