restart;

kernelopts(version);

   Maple 2016.2, X86 64 LINUX, Jan 13 2017, Build ID 1194701

SolveTools:-SemiAlgebraic( {x^2+y^2+z^2 = 3, x+y+z = 3} );

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

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

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

[edit] As for unloading the RealDomain package, try calling,

unwith(RealDomain);

Note that the RealDomain package also exports things like `^`, so it matters if you constructed expressions before you unloaded the package. You can also force use of the so-called global commands, even when that package is loaded, using the colon-dash syntax. (It can get hard to read, though.)   RDstuff.mw

I've been meaning to put this into a Maple 2017 cloud-package, after clean-up, re-factoring, and adding a Help page.

But attached below is a Document with your example.

The code which does the "degree-polar" stuff in in the Startup Region of the Document.

(I have to make some more adjustments, I see, since while revising to handle units in this "version" of it I've managed to make it lose some float-contagion. That just means that it keeps turning floats into exact rationals when combining the quantities. That's why I use evalf below. You could also use the right-click content-menu item "Approximate" when you want to turn results into float approximations. Earlier versions were here.)

In Maple 2017's GUI itself the units display more nicely.

Download degreepolarexample.mw

Perhaps one of these two (similar) approaches would work for you.

(Sorry, Mapleprimes doesn't seem to want to inline this attachment).

cross.mw

for i from numelems(arr) to 1 by -1 do
    # do something
end do

Or,

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

There are several variations on these ideas. I've tried to do it so that the calls to plot take the argument DV = -5 .. 5 (ie. expression form, rather than operator form with just the range -5 ..5 ).

Note that I use two-argument eval (aka "evalat"), for example to evaluate the set of equations like {x=1.200, y=3.567} to extract the values 1.200 and 3.567. I consider this better than using a few op calls, or rhs of an indexed entry, etc, because it stands up when you change the variables names to things with a different lexicographic ordering, and it's also more clear what it's doing.

DVplot.mw

ee:=3*d^2+f^2-4*e^2+2*t*d^2-4*t*e^2+2*t*f^2+3*f^2+4*t*d^2;

                         2        2        2        2      2      2
                ee := 6 d  t - 4 e  t + 2 f  t + 3 d  - 4 e  + 4 f

collect(ee,[d,e,f]);

                               2               2              2
                    (6 t + 3) d  + (-4 t - 4) e  + (2 t + 4) f

Most Library commands are not thread-safe and will not function properly under the Threads package.

That includes `int` and `evalf/int`.

If your individual pieces are not too fast to compute then you could consider using the Grid package instead.

The problem may be related to entering Qgr in 2D Input mode, but I have yet to narrow it down.

The way you have defined your procedures (operators) the value of h is not taken until those procedures are called. So the value of h is not relevant at the moment the procedures are created.

When your loop is finished, the value of h is 51.

You problem is really about how to create a procedure with certain parameter values explicit in the procedure body. You problem isn't really about loop indexes. The name h needn't be a loop index, in order to have your need, is what I mean by that.

One way to get around this (quite intended behavior of procedures) by Maple is to declare h as global within the procedures. Since I consider using global variables to be poor programming I don't recommend this approach.

One popular other way is to use the unapply command from an expression in which the name h has already been replaced by a value. That's often short and convenient to do, but might not always suffice (or could be awkward to do properly) if your expressions aren't something you'd want fully evaluated. For your example the wrapping call to evalf is just such a wrinkle. See below.

Another way is to substitute the current value of (the loop index) h in as a replacement for a dummy name in a procedure (which acts like a template, then). This is more keystrokes, but pretty powerful.

You haven't show us the nature of any entries in and Q[i], or and x1[i] or y1[i] (for any i). So below I'll make something up.

If neither of these two approaches work for you, then upload the full code as a worksheet (big green arrow) and I expect it could be ironed out.

Download scope.mw

I should also mention that you can print the bodies of the procedures, to see/check how the two approaches work (while differing in nature from each other). Notice how one of these has replaced all of the Q[i][j] and x and y, etc (which you may or may not want to have happen), while the other has not.

eval(Z[2][1]);

           s -> evalf([s, -s])

eval(Z[2][2]);

    s -> evalf(subs(x = x1[2](s), y = y1[2](s), Q[2][2]))

For the simple example shown, those approaches produce the same result. I could mention that the second will be slightly less efficient to run as each call to the procedures assigned to the Z[i][j] will perform the subs work (and so there would be duplication of effort when the same procedure is called for multiple values of the input s).

Yes, there is something akin to automatic simplification that can take place with the infix form of and yet not with its prefix form. Actually it's more of a premature evaluation under evalb (see below).

[ edit: removed confusing poor comparison with automatic simplification of f()+f() vs `+`(f(),f()). ]

The help page for and mentions evaluation of strict equality under evalb. That also affects `<>` by which I mean unequal. For the infix form of and the evalb evaluation causes instances of infix `=` and `<>` to prematurely become just true or false. (It's not an exact analog to f()+f() since that cannot be prevented from simplifying automatically to 2*f() prior to evaluation of f() through use of single left quotes aka uneval quotes. But as you've seen there are similarities, I think.) This affects mixtures like say,

   u>0 and x<>y

which becomes just u>0 via u>0 and true . For the prefix form the evaluation of the `<>` part doesn't happen right away.

T:=`and`(u>0, x<>y);
                    T := 0 < u and x <> y

lprint(eval(T,1));
  0 < u and x <> y

T; # causing another evaluation
                            0 < u

Notice that the first result in the group above has the infix form as output. The effect here is that eventually (with enough evaluations) the x<>y will become true (because of the and). If it weren't for the wrapping and then the x<>y would not get hit by evalb and thence evaluate to true.

R:=x<>y;
                         R := x <> y

R;
                           x <> y

evalb(R);
                            true

One way to deal with this kind of thing is to use the prefix operator And instead of and.

Some of your other difficulties seem due to confusion between types and properties. For example is and assume deal with properties. They know of a real property. But there is no type real, so type evaluation (of double-colon, under evalb, under and)  produces the error message to that effect.

Your very last example does look like a weakness in Re.

I've heavily edited my Answer, trying to make my terminology more precise.

Using convert(...,base,2) ,
 

Download b2.mw

You forgot the colon when trying to assign to `eq`.

You used only = instead of := and so you created an equation instead making an assignment.

Your original question was not clear about whether you wanted to pick off names according to the prefix or the subscript.

My Answer gets the names with a particular prefix. And of course you could use select instead of indets if your actual goal is to obtain the subexpressions in poly rather than just the suffixed names.

But if your actual goal is to get the names/subexpressions that have a particular "subscript" then see Carl's Answer.

restart;

poly:=a__b+b__a+a__b^2;

                                   2
                       poly := a__b  + a__b + b__a

indets(poly, 'suffixed(a__)');

                                  {a__b}

indets(poly, 'suffixed(b__)');

                                  {b__a}

another:=a__b+b__a+a__b^2+a__4^3*a__c;

                         3            2
          another := a__4  a__c + a__b  + a__b + b__a

indets(another, 'suffixed(a__)');

                       {a__4, a__b, a__c}

indets(another, 'suffixed(a__, integer)');

                             {a__4}

indets(another, 'suffixed(a__, name)');

                          {a__b, a__c}

indets(another, 'suffixed(a__, identical(c))');

                             {a__c}

With the values for some variables set as in special below, then is it not clear that there are infinitely many solutions for the remaning variables, if r22 is taken between -1 and 1?
 

Download polysys2.mw

First, a few comments:

A few years (Maple major releases) ago the style of Help pages was changed so that Execution Group Boundaries were hidden from view in most Help pages Examples. The default setting for non-Help Documents and Worksheets is that Execution Group Boundaries are shown, however. That's the reason you see the mismatch between what appears in the Help page and what happens when you type the example into a fresh Document or Worksheet.

As Samir mentions, you can toggle the setting yourself, obtaining the non-default display that matches the current/modern Help pages.

nb. If, from the Help browser, you open the help page as a Document in the main Maple window then it retains its setting w.r.t. display/hiding of Markers like Execution Group Boundaries. So with default settings for File->New Documents/Worksheets (that show such Markers) you'll also see a mismatch between a fresh New Document and a Help page opened as Document.

Now, a suggestion:

I notice that your attachment is a Document, rather than a Worksheet. The more common unit for input/output in a Document is the Document-Block (which wraps around some Execution-Group) rather than the bare Execution-Group. An Execution-Group contained in a Document-Block does not get its Execution Group Boundaries shown. And so it seems to me that a Document-Block would provide an alternative, natural mechanism to get the effect you seem to want (of a Document's style) in your Document.

nb. The main menubar's View->Markers checkbox controls whether Document-Block boundaries are shown. Note that -- when shown -- those appear in a thin column to the left and outside of the actual sheet, whereas boundaries of bare Execution Groups are shown as black brackets within the actual sheet.

Here's an attachment where I have left the View->Show/Hide Contents...->Markers->Execution Group Boundaries toggled on. 

Download displayDocBlock.mw