@radaar In your latest example, the first x is global (as you noted), all of the xs in ff are still a formal parameter (this time with a default value), and the x in ff(x) is an argument as well as a global. There is no connection between the formal parameter x and the other xs other than that they have names that are just coincidentally spelled the name. 

I don't know if you had any question about this example. There's not much subtlety involved here, and none of this is adequate to describe PLBVs.

@radaar The first x, in x:= 10, is a global variable (assuming that this code occurs at the top level). Any xs in procedure f are called formal parameters (because the declaration of x is in the procedure's header). This distinction between global variables and formal parameters is similar to the distinction between free and bound variables, although the latter distinction is far more subtle. The former distinction has no "gray areas".

The terms "place holder" and "dummy variable" are often used in the same contexts as local variable, formal parameter, and bound variable. I prefer to not use the former terms because they're not as precisely defined. And, referring back to your original Question, none of these terms, nor any combination of them, is adequate to precisely descibe the special status of the bound variable of seq, add, or mul.

@radaar See my Answer below. There are only three commands that have this exception---seq, add, and mul---and the exception works exactly the same way in all three.

@Kitonum In most ways, but not all ways, ii can be thought of as local. A case where its status is somewhere between local and global is 

a:= ii^2; seq(a, ii= 1..5);
             1, 4, 9, 16, 25

@janhardo No, there is no benefit to having the inner loop. Indeed, it's very wasteful. Each statement in the inner loop is being executed 3 times for each value of i.

Show some respect for the people who read your Question. This might require some actual typing on your part. 

@mmcdara The inappropriately named command convert(..., polynom) does only one very specific thing: It converts a series representation to an ordinary algebraic expression. The most-obvious manifestation of the conversion is the absence of the series's O(...) term. A better name would be convert(..., from_series).

@Carl Love I said above that you can get back up and running by doing the three simple steps Save => Close => Reopen. There are occasionally cases where that doesn't work---the Save on the menu is grayed out. Here's a simplified version of the protocol that works even in those cases (in addition to working in the original cases):

1. Attempt to close the worksheet by using the X on the right side of its tab on the tabs bar (not the X that closes the whole Maple window!!).
2. You'll be interupted by a Save dialog, and you accept it.
3. Reopen the worksheet.

You'll also be interupted be the reappearance of the "Kernel Connection Lost" dialog. Just dismiss it.
 

@mmcdara The difference between in and = is purely syntactic; the difference between the set and list forms is not. When there are non-syntactic differences between two forms, the brevity has nothing to do with my choice. In that case my decision is based on efficiency.

@mmcdara It's 2 fewer characters; that's the only reason.

@Earl In my Answer above, note this command

plots:-implicitplot3d~([p1,p2], -12..5, (-7..7)$2, grid= [50$3], color=~ [red, blue])

It uses elementwise operators (~) to create two implicitplot3d commands with colors matched to p1 and p2 respectively.

@PatD Oddly enough, there is a built-in solution for the equivalent situation with sum and Sum, but none (at least none documented) for products. It is deeply buried in the Physics package. See ?Physics,Library subsection Add.

@Earl I don't see how it could be done with a "stock" Maple plotting command. But it's possible to write a brief "wrapper" procedure that calls a stock plotting command and passes it the function as well as other options, including color. Then this wrapper effectively becomes a new higher-level plotting command that does what you said. I've included several examples of these wrappers in this Post: "Numerically solving BVPs that have many parameters". (The Post is not about plot wrappers per se.)

@Axel Vogt You could try 4-sided dice, which would avoid the too-many-bins problem.

But I think that any robust method for this must address the run lengths. Note that my test decides overwhelmingly---with an odds ratio of more than a thousand---that sequence A is the one that's not truly random.

@Axel Vogt The chi-squared test of course uses a continuous approximation of a discrete distribution, essentially an elaboration of the normal approximation to the binomial. That approximation is usually considered worthless if the expected count in any bin is <= 5. Unfortunately, the Maple command does not check this. Your expected bin counts are (25 values / 5 bins = 5), so all of your bins are in violation of this criterion.

That is why my run-length chi-squared test has the line while E > 10 (where E is about to be divided by 2 before being used). Once E is less than 10 (but still greater than 5), all remaining run-length counts are lumped into the final bin.

@vv Yes, a string has several runs. Now imagine that we have no foreknowledge of the length of the string. Select one of the runs uniformly at random. What is the probability that it's length is k? It's given by the formula I gave. (Note that the sum k= 1..infinity of that formula is 1.) For p=1/2, the formula yields 1/2, 1/4, 1/8, etc. 

A small adjustment needs to be made because we do have foreknowledge of the length of the string. But some empirical testing with rand(0..1)() ​​​​on strings of lengths in the thousands shows that approximately 1/2 of all runs are length 1, 1/4 length 2, etc., and that those approximations are very close.