@CyberRob The problem is that in what you said that you were "expecting", you have treated nurdel differently from the other variables. The operand numbers that Kitonum used are the only needed for that special treatment. I think that you just made an oversight about nurdel. In that case, the solution given by simply factor should be good enough.

Acer, I'd be pleased to see your critique of the above. It's the first time that I've done "surgery" on ToInert of a procedure.

@shkarah Since I don't use or even have a copy of Excel, it'd likely be better if someone else answers.

Show me what happens when you use the command that I gave you:

ExcelTools:-Export(op([1,1], P[H]));

@Stretto 

You can give parameters default values like this:

f:= proc(x, y:= 1) x^2+y^2 end proc:
f(3), f(3,2);
                             10, 13

The syntax rules for this are

1. It must be a proc, not an arrow expression (lambda expression).
2. Parameters with default values must occur after those without them (if there are any).

I guess that you, Stretto, posted a Question about how to handle the situation when a parameter name is also globally assigned a value. Here's how. Any Maple structure, including a procedure, can be put into an inert form with command ToInert. This produces an elaborate tree structure of nested functions (whose names all begin _Inert_). In this form, names appear as strings, so they don't evaluate. The command parse will convert these strings back to unevaluted names. However, at that point, any such name that has an assigned value is like a "Cinderellla" that'll turn back into its value as soon as you try to use it. This can be prevented by convert(..., `local`).

I've changed my procedure Params to do all this. My procedure Iter didn't need any changes:

Params:= proc(f::procedure)
option remember;
local r:= [op(map(Param, op(1, ToInert(eval(f)))))];
    if r[-1]="$" then
        error "end-of-parameters marker $ not allowed"
    else
        convert~(parse~(r), `local`)
    fi
end proc
:    
Param:= (e::function)->
    if e::specfunc({_Inert_NAME, _Inert_ASSIGNEDNAME}) then op(1,e)
    elif e::specfunc(_Inert_SET) then
        error "keyword parameters not allowed", FromInert(e)
    elif e::specfunc({_Inert_ASSIGN, _Inert_DCOLON}) then op(thisproc(op(1,e)))
    else error "unknown InertForm", e
    fi
:
Iter:= proc(f::procedure, n::nonnegint, p::posint:= 1)
local P:= Params(f);
    if n=0 then subs(_P= P[], _F= P[p], _P-> _F)
    elif n=1 then eval(f)
    else 
        subs(
            _P= P[], 
            _F= f(P[..p-1][], thisproc(f, n-1, p)(P[]), P[p+1..][]), 
            _P-> _F
        )
    fi
end proc
:
#Examples:
y:= 1: #Assigned value
for k from 0 to 3 do Iter((x,y)-> f(x,y), k) od;

        (x, y)-> x
        (x, y)-> f(x, y) 
        (x, y)-> f(f(x, y), y)
        (x, y)-> f(f(f(x, y), y), y) 

@Stretto 

You have put forth a formal logical argument, claiming that three of my statements are contradictory. Specifically, you said:

• You say: "An unassigned x is not an integer." " Integers are polynomials." " As I said in the other thread, if a and b are not defined, then they're explicitly polynomials"

  But these are contradictory statements. If a is not defined then it is an explicit polynomial... integers are polynomials. An unsigned/undefined a is not an integer.

From decades of experience, I've learned that it's futile to argue with someone who doesn't accept the fundamental rules of logic. My three statements above are not contradictory. This can be verified many ways, including by the most simplistic of logic algorithms: the truth table. Indeed, it can be done in Maple, thus:

restart:
with(Logic);
#Let  A = Assigned, P = Polynomial, Z = Integer

#Propositions: 
#    S1 = If a symbol is unassigned, then it's a polynomial:
S1:= (&not A) &implies P;

#    S2 = Integers are polynomials:
S2:= Z &implies P;
 
#    S3 = If a symbol is unassigned, then it's not an integer:
S3:= (&not A) &implies (&not Z);

TruthTable(S1 &and S2 &and S3);

There's no point in my trying to convince you of anything, let alone that gcd(a,b)=1 is correct (even without making any idiosyncratic assumptions), if you don't understand why those three statements are not contradictory.

@vv The value of module variables when they come out of a library is the same as when they were put in. For seed, this may not be 1. I'd rather that the initial value be universally constant (from one user's system to another) regardless of whether they saved the module before or after using it.

It is a very minor point in this case, which is trivial, but my purpose is to teach that point for those cases where it's more important.

As I said in "Primer...", the ModuleLoad is only there so that the module will work even if the module were stored in a library, even though it isn't. Module bodies (in this case the body is just the statement seed:= 1) are not stored in libraries. The bodies get garbage collected immediately after they're executed. This is why, unlike procedures, you cannot see the overall code of a stored module. You can only see the code of the module's procedures, individually.

I'll leave this Reply here because there's often confusion about why a ModuleLoad and module body are often both present: The ModuleLoad is only executed if the module does come from a library; the module body is only executed if the module does not come from a library.

You a have discovered a bug, but I wouldn't exactly call that "a simple integral". Note that there's no symbolic antiderivative (that Maple knows) even for the simpler exp(cos(t)). Your example is one of those definite integrals that can only be solved for very special intervals of integration.

@Christian Wolinski Like the OP, I get 0, and I have a legitimate copy of Maple 2019. So, it's a bug.

Like the other respondents, I immediately saw that what you were trying to do (other than the part about preserving the names) is essentially covered by foldl (or `@@` in the univariate case). And I largely share Acer's misgivings about preserving the names. However, the fact that it's possible to do what you want with a short procedure is one of the things that I find so compelling about Maple, so here's a recursive implementation of Iter:

Params:= (f::procedure)-> op~(1, op~(1, [op(1, eval(f))]))
:
Iter:= proc(f::procedure, n::nonnegint, p::posint:= 1)
local P:= Params(f);
    if n=0 then subs(_P= P[], _F= P[p], _P-> _F)
    elif n=1 then eval(f)
    else 
        subs(
            _P= P[], 
            _F= f(P[..p-1][], thisproc(f, n-1, p)(P[]), P[p+1..][]), 
            _P-> _F
        )
    fi
end proc
:
#Examples:
for k from 0 to 3 do Iter((x,y)-> f(x,y), k) od;
        (x, y)-> x
        (x, y)-> f(x, y) 
        (x, y)-> f(f(x, y), y)
        (x, y)-> f(f(f(x, y), y), y) 
#Iterate on the 2nd position by using the optional 3rd argument:
Iter((x,y)-> f(x,y), 2, 2);
        (x, y)-> f(x, f(x, y))

Note that I've avoided any use of unapply by careful use of subs.

Warning: This ignores the possibility that the parameter names have been assigned values as globals.

Edit: That assigned-global problem is solved in a Reply below.

@shkarah For each value of H, do

ExcelTools:-Export(op([1,1], P[H]));

@digerdiga You asked:

• The Float() are just the rational numbers n/101 where n=0...100 or?

Yes, rational numbers in decimal (or "float") form.

• I guess that's what happens also with other generators?

As far as I'm aware, most PRNGs (and certainly all those commonly used in Maple) work by first generating integers uniformly in some interval and then transforming them to the form requested by the user.

• Why do you call the procedures
      ModuleApply:=...
      ModuleLoad:=...
  ? Do these names serve any purpose?

Yes, the procedure names ModuleApply and ModuleLoad (as well as several others that begin Module...) have special meaning to Maple, and you can read about them on their help pages. Briefly, ModuleApply is the procedure that is called if the module's own name (Rand in this case) is invoked as if it were a procedure, e.g., Rand(), and ModuleLoad is a procedure that is called when the module is read from a library (which doesn't actually happen in this case because the module's code appears directly in the worksheet).

@Glowing So, as far as you're aware, Maple 2019.2.1 is the only multiprocessing application with which you cannot achieve 100% CPU utilization?

@kfli I think that you misunderstood my Comment. I'm not suggesting that you shouldn't use multiprocessing. I'm suggesting that you not use multiprocessing just for the final step---the conversion of a 3D Array to a Vector. That step is a triviality if done with Alias.