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

You can apply the commands lhs and rhs to a range such as 1490.90920124091 .. 1497.18170785000 in order to extract the end-points.

expr := 1490.90920124091 .. 1497.18170785000:

lhs(expr);
                   1490.90920124091

rhs(expr);
                   1497.18170785000

I can reproduce the problem in Maple 17.02 on a 64bit OS X host as well as on a 64bit Linux host.

The problem seems (at least in part) to be in the `combine/ln` procedure, but I have not really dug down into that.

restart; kernelopts(printbytes=false):                                                         

kernelopts(version);

            Maple 17.02, APPLE UNIVERSAL OSX, Sep 5 2013, Build ID 872941

`combine/ln`:=u->u: # extraordinary measure

ans:=CodeTools:-Usage( int(3628800/(y*(1/2+y)^11)
                           -3628800/(y*(39/2+y)^11), y=39/2..infinity) ):
  memory used=13.75MiB, alloc change=32.00MiB,
  cpu time=218.00ms, real time=321.00ms

lprint(ans);                                                                                   

 87385605194015325709926400/3919454781758919*ln(2)-7431782400*ln(3)
 -7431782400*ln(13)-53097887349433051488808628851346857/
 282200744286642168000000000+7431782400*ln(5)

And now, after restart,

restart;
ans:=87385605194015325709926400/3919454781758919*ln(2)-7431782400*ln(3)
 -7431782400*ln(13)-53097887349433051488808628851346857/
  282200744286642168000000000+7431782400*ln(5):

combine(ans);
memory used=49975.3MB, alloc=2666.1MB, time=189.08
memory used=51387.2MB, alloc=4078.1MB, time=189.75
memory used=52093.2MB, alloc=4784.1MB, time=189.77
memory used=52097.7MB, alloc=4784.1MB, time=189.84
memory used=52099.3MB, alloc=4785.4MB, time=189.85
Interrupted

Another workaround for the given example is to force the ftocms method of the int command.

restart; kernelopts(printbytes=false):

ans:=CodeTools:-Usage( int(3628800/(y*(1/2+y)^11)-3628800/(y*(39/2+y)^11),
                           y=39/2..infinity, method=ftocms) ):
memory used=15.56MiB, alloc change=24.00MiB, cpu time=210.00ms, real time=314.00ms

lprint(ans);
 -53097887349433051488808628851346857/282200744286642168000000000
 +7431782400*ln(40)-29128535064671775175475200/
 3919454781758919*ln(39)-91750400/3919454781758919*ln(78)

oldans:=87385605194015325709926400/3919454781758919*ln(2)-7431782400*ln(3)
  -7431782400*ln(13)-53097887349433051488808628851346857/
  282200744286642168000000000+7431782400*ln(5):

simplify(ans - oldans);

                                     0

Here is a simpler instance of trouble within `combine/ln` . In Maple 

restart;                                                        
kernelopts(version);

        Maple 17.02, APPLE UNIVERSAL OSX, Sep 5 2013, Build ID 872941

expr:=87385605194015325709926400/3919454781758919*ln(2)-ln(3):

combine(expr);
memory used=195798.0MB, alloc=2666.1MB, time=25.01
memory used=198455.8MB, alloc=5324.0MB, time=26.77
memory used=201156.1MB, alloc=8024.2MB, time=29.39
Interrupted

Now, you wouldn't want `combine/ln` to never do anything, as in my crudest workaround at top.

I might be able to figure out how to patch your Maple 17.02 `combine/ln` (say as a "hotfix" with ToInert/FromInert to avoid copyright issues). If I do I'll let you know. (It might be related to the elif d = 1 then clause shown around line 92 under showstat(`combine/ln`) in your version. A preliminary attempt shows your example succeeding after that... but it'd require more examination. Such a change would, I suspect, return the shorter, simpler example above unchanged by combine.)

That link you gave indicates that within Matlab you can issue a command of the form

maple( ' ... ' )

and have the statement enclosed in single right-quotes be dispatched to the Maple symbolic engine. Is that correct?

If that is the case then (as I mentioned to you on stackexchange) you could use the Maple command zip to obtain a Matrix of equations from two given Matrix exp1 and exp2.  Did you try,

maple('zip(`=`,exp1,exp2)')

where the symbol `=`  is enclosed in single left-quotes?

Each of the commands evala , rationalize , and radnormal succeed in getting that form in Maple 17.02.

Using the avoid option of fsolve seems to be another way to get two distinct solutions.

Using 64bit Maple 2017.2 for Linux this worked for me at default Digits=10, without having to restrict the ranges narrower than the given 0<=beta,delta<=1 .

Download bivar.mw

An earlier post of yours was marked as Product: Maple 18 , which would explain why you are not always getting the same results from other members here, using just the simplify command.

If that guess is true then please mark all your Mapleprimes Questions as Maple 18 for the Product.

In the attached worksheet I show how you can get simpler results using Maple 18.02.

Download simp18.mw

Use time[real]() instead of time() to compare wall-clock timing.

(...and make sure that your machine is not otherwise loaded.)

You could also wrap the call with CodeTools:-Usage . Note the "cpu time" shows the addition from all threads (concurrent or otherwise), which is why you need to compare real-time instead. Eg,

restart;
N:=1000000: with(Threads): CodeTools:-Usage( Seq(sqrt(i),i=1. .. N) ):
memory used=1.21GiB, alloc change=302.20MiB, cpu time=11.41s, real time=2.99s, gc time=3.23s

restart;
N:=1000000: CodeTools:-Usage( seq(sqrt(i),i=1. .. N) ):
memory used=1.21GiB, alloc change=247.64MiB, cpu time=9.14s, real time=6.47s, gc time=4.34s