Technically, by itself the $ limits the number of arguments but does not specify that any argument must be passed. That's because even the so-called "required" parameters may not be checked until accessed/used. (See 3rd example in my attachment.)

Maple's quite happy to have a procedure which is defined with say 5 parameters only ever use the first 3 of them. (See 1st example in my attachment.) 

And optional parameters (eg. keyword, positional parameters) muddy things even more. (See 2nd example in my attachment.) And the seq modifier must surely make quite the muddle.

This is all partly why this kind of information is very rarely used, even by experts. It's possible that the OP is trying to do something very specialized, where the 1st operand of the procedure is actually some useful thing.

But I suspect more that the OP is trying to do something much more common, likely related to nargs and _nparams and related counts of the number of arguments that actually get passed into the procedure when called.

params.mw

(I'm sure Carl knows all this. I hope he forgives my adding a note... to the world.)

@gmzsvsclk 

collect(E,[q,w],distributed);

@Fzen 

For your amusement you can rearrange the by, while, and from parts.

for i by -1 while i>0 from numelems(arr) do
    # do something
end do

Please put your followup details in Comments to this Question, rather than spreading the issue across additional, disjoint Questions.

@juju1234 There were some major changes to 2D Input in Maple 2017, and there have been a few reports of bugs in the results of using the Matrix palette.

I have not been able to recreate the problem, however, using the same steps that you've described. I've tried Maple 2017.0, 2017.1, and 2017.2 (and your document matched one of those...).

If you don't want to have to keep saving/re-opening then you could try entering your Matrix (even in 2D Input mode) using either the Matrix(...) or the <...> constructors. I suspect that then you would be able to go back and edit the input line's Matrix entries without this issue.

@vv I believe that the delayDotProduct is not the cause of the posted error. The posted error appears to be in the handling of the parameters a and b used in the operator for `=`. I suspect a problem in Typesetting:-Parse or possibly ToInert.

As the OP mentioned, changing the names of the parameters in the problematic operator resolved the error. I saw the same, with even changing just parameter a to say aa.

I don't know exactly how it is becoming confused. It's possible that one of the earlier instances of parameters named a is being reused by mistake somehow, during parsing. Just a guess.
 

Download areiso.mw

@tomleslie Agreed the question makes little sense as written.

Perhaps he wants,

  convert(a, rational)

or,

  convert(a, rational, exact)

What do you want it to look like?

@Volker Lehner I suggest that you switch your GUI settings (preferences) so that by default you get "1D Maple Notation" input instead of "2D Input", and a "Worksheet" instead of a "Document".

Manual editing of 2D Input is awkward and buggy.

Please upload the document, so that we could examine it. Use the green up-arrow in the Mapleprimes editor.

@tomleslie I interpreted Christopher's comment as being general, and so was my answer. As such, both are accurate.

You'd already made your points about the fitting periodic data/functions in your answer. It might not be the case here, but in general your claim is wrong that local vs global solutions don't come into it. A nonlinear fitting problem could have both a globally optimal fit (according to some metric) as well as a one or more inferior locally optimal fit (by same metric), both of which could be accompanied by their respective equivalently good fits at periodic intervals.

@Christopher2222 The issue is that the Statistics:-Fit command utilizes local optimization solvers, and for a nonlinear problem the local minima may exist which are not (even very close to) the global mimimum. What is so wonderful about the DirectSearch package is that not only does it contain global optimization solvers but it also contains curve-fitting/regression front-ends which utilize those solvers. And those curve-fitting commands also have a healthy choice of metric (ie. defn of residuals by several formula, allowing for various concepts of "best fit").

@itsme 

I notice that site has already been updated (both comments and functionality chart) since you first posted this, and following the discusions above. (I too wonder why comments were deleted.)

These seem to work, as of Maple 2017.0 ,

is(`Or`(k::posint, k::negint, k = 0)) assuming k::integer;

                              true

is(`Or`(k::negint, k::nonnegint)) assuming k::integer;

                              true

is(`Or`(k::posint, k::nonposint)) assuming k::integer;

                              true

@Carl Love Quite a bit of the time seems to be spent in convert(...,listlist) and in the Matrix constructor.

Does this produce the same result, just with listlist until the the subtraction?

It gets me about a factor of six better timing.

restart:
gc():
st:= time():
n:= 6:
N:= [$1..n]:
Sn:= combinat:-permute(n):
Id := [seq([seq(0,j=1..i-1),1,seq(0,j=i+1..n)],i=1..n)];
MF:= {seq(Id+Id[d,..], d= remove(p-> ormap(evalb, p =~ N), Sn))}:
MA:= {seq(seq(M[p,..], M= MF), p= Sn)}:
Ones:= Matrix((n$2), 1):
MA:= {seq(Ones - rtable(M,subtype=Matrix), M= MA)}:
time() - st;

Assuming that I haven't inadvertantly broken it, on my machine this seems to indicate that about half the time here is spent in producing Matrices from the listlists.

restart:
gc():
st:= time():
n:= 6:
N:= [$1..n]:
Sn:= combinat:-permute(n):
Id := [seq([seq(0,j=1..i-1),1,seq(0,j=i+1..n)],i=1..n)];
MF:= {seq(Id+Id[d,..], d= remove(p-> ormap(evalb, p =~ N), Sn))}:
MA:= {seq(seq(M[p,..], M= MF), p= Sn)}:
MA:= eval(MA,[1=0,0=1]):
time() - st;
MA:= {seq(rtable(1..n,1..n,M,subtype=Matrix), M= MA)}:
time() - st;