@Stretto I understand (and did understand) exactly what you want; no further explanation of that is necessary; I don't need to see (nor did I ask to see) a worksheet of your original problematic output; I know that it puts b under c. In order to help you properly, I need to see the output of

interface(version); interface(prettyprint); interface(typesetting);

You make it exasperating for us to help you, and exasperating for yourself, by going off on tangents, such as what happens for expressions with exponents.

@Rouben Rostamian Your solution works if k evaluates to a name (as opposed to, say, a number), and f behaves reasonably when given symbolic input. If either of these things are not true, unevaluation quotes are needed, as in

['f(k)' $ 'k'= 0..5]

One thing that I like about ~ is that it doesn't require introducing a bound variable, the k in this case.

If speed is a concern, seq is usually faster than either of these, and also faster than map. Unfortunately seq has ugly syntax.

@Stretto You're right, it's no different. To answer properly, I need to see exactly how it displays on your screen. Can you post an executed worksheet?

If you're using the command-line interface, I don't think that it's going to be possible to get the display that you want.

If you want it to simplify to 9, just use the regular operators, not the inert ones.

@Stretto Unfortunately, the % operators do not have the same precedence as their regular counterparts. I'll admit that this is bad design on Maple's part. So, you need to use parentheses to clarify:

(3^3) %/ 3

This is different from (3^3)(%/3). This latter expression is probably something that you'd never actually want. And I'll explain what it does, if you'd care to know.

To answer properly, I need to know exactly how the output of the things that you show appears on the screen. The copy-and-paste mangles it.

If you give the command 

interface(displayprecision);

what is the result? If it's anything other than -1, then do

interface(displayprecision= -1);

Then explicitly delete the plot output (Ctrl-Delete), and rerun the plotting command. I'm just guessing that this might work.

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