@max125 There is a help page for topic solve/parametric . For your example I used that calling sequence (along with the real option) as a way to invoke SolveTools:-SemiAlgebraic.

I went for that because your problem was a polynomial system and your wanted only real results.

For other kinds of system the goal of obtaining only purely real solutions can get very difficult indeed, and obtaining all real solutions harder still. Sometimes it's not even possible to do in Maple.

@Markiyan Hirnyk 

solve( {x^2+y^2+z^2 = 3, x+y+z = 3}, real, parametric );

                        [[z = 1, y = 1, x = 1]]

@NeillSmith Yes, one way is to put such definitions you like into a personal initialization file. That's relatively easy.

Another slightly more advenced way is to use LibraryTools:-Create  to make a .mla Library archive file, and then to use LibraryTools:-Save to store the procedures to that archive. (And you can store other stuff in it later, too. But keep a copy of the worksheet that actually builds the .mla archive and defines stuff and stores them. Handy for later revisions. You can just keep it in the same folder.)

Then you call augment libname in the initialization file, eg,

libname := "somenewfolder/foobar.mla", libname;

A tip: You should be able to create an alternate "launcher" for the Maple GUI, which passes the -s option and so starts without reading the initialization file. Sometimes useful for checking that weird behavior isn't due to such customizations. This can apply to either scenario: whether you put code definitions of libname adjustments into the init file.

@NeillSmith Please see the followup Comment to my Answer, which has further examples using equations and Equation Label references which do just what you now describe.

So do you generally want to first express the abstract computation (ie. like &* of deprecated linalg package) which you could only later force to compute explicitly (analogous to say hitting with evalm in the linalg sense)? An abstract implementation of the LinearAlgebra functionality is a long-standing general request, not only for the purpose of mathematical display but also for the serious task of expression manipulation/rearrangement.

Attached is a Document using the same two implmentations, but with examples using Equation Label references.

It works for me, using Maple 2016.2.

With one set of uneval quotes the Equation Label can be referenced (within a call to lhs) inside eval(...,1) for single-level evaluation. With two sets of uneval quotes the Equation Label can referenced as is (within a call to lhs).

cross_eqnlabels.mw

note. While Mapleprimes did not successfully inline the attachment, it does let me insert just the link.

@tomleslie The Question's tagged as "Maple 2016", and in version Maple 2016.2 your suggestion doesn't work. The call using uneval-quotes produces output with an unevaluated call to Typesetting:-delayCrossProduct . That's partly why he asked, I believe.

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.