You already knew about assignment statements, and I suspect that you also knew about ways to concatenate names. You've put these actions together.

Note that it is only practical in a modest number, and since the generated names are always global it's far less useful as a programming technique.

Also, each global new name will get checked against the assigned names stored in all .mla and .m files in libname (once at least, up to first evaluation). That seems to scale roughly linearly, IIRC. I once saw an example with a 15sec wait in the computation where the kernel was doing nothing but i/o overhead.

So it's sorta, kinda ok as an off-the-cuff thing at the top-level, but in my opinion doesn't belong in a group of solid programming techniques for serious production line work.

You might consider this (although nothing is fool-proof),

  select(u->is(u,real), evalc~(allvalues~(coef7))) assuming alpha[1,2]::real, alpha[2,6]::real;

or, since it is only the two assumed names as dependent names,

  select(u->is(u,real), evalc~(allvalues~(coef7))) assuming real;

I declared z as local outside the do-loop as, alas, the 2D Input parser doesn't accept your original.

Download G2_ac.mw

You might consider editing your procedures in 1D plaintext Maple Notation (in Execution Groups, or Code Edit Regions).

ps. I am curious, is your task going to go anywhere near the LinearAlgebra[Generic] subpackage? (I know nothing of "Domineering".)

You haven't stated why LinearAlgebra:-LinearSolve is not adequate for your computations. You haven't mentioned whether you are doing purely floating-point computations, and if so whether those are purely real.

I would not be surprised if you needed some large examples (or a great many of them) before the LinearSolve overhead became a bigger bottleneck than anything else in your code -- as a tentative judgement based from general experience with member's code.

But, below is an example that uses the floating-point real tridiagonal linear solver from LAPACK.

This uses two functions, one to do the LU decomposition and another to do the back/forward substitutions for one or more RHSs.

Hopefully I got the integer array's widths correct -- I might have forgetten some detail of the linkage model in use.

As I mention below, this has a little extra overhead (probably avoidable, using other access means).

This was run on Linux. To run on MS-Windows you'd have to changed the name of the external shared library, from "libmkl_rt.so" to the appropriate .dll. And even then it might run amok of MS-Windows awkwardness.

Download DGTTRF.mw

There are a few things that can be said.

1) No, it is not necessary to use active int for this. In fact doing so can be unnecessarily very expensive, since it can cause the integral to be attempted symbolically for each new call to the objective procedure (where each might fail, after a while). See first example in the attached.

There can sometimes be a mixup for Mimimize when called with procedure (rather than expression) form for the objective. It happens more rarely then it did long ago. It's caused mostly by some muddle about generating a procedure for evaluating the derivative numerically, via automatic differentiation. My first example does a few things to avoid that.

2) Your second bullet point sounds like it might be an evaluation mix-up. See the last example in the attachment with proc4, which may be what you were looking for here. The point is to keep straight that the K,r,x in globally defined df are themselves global (whereas the K,r in proc4 are procedure parameters). It helps to always test the objective procedure at a single candidate point, as sanity-check. Sorry if I misunderstand you here.

3) There's a battle between the numerical optimizer's wish to establish an optimum that satisfies its optimalitytolerance control option's value versus the numeric integrator's specification to only provide a result that needs to be convergent up to its own accuracy tolerance option epsilon. I know that sounds like a mouthful, but analogous struggles can happen between evalf/Int, fsolve, and Minimize. The "outer" one needs the "inner" one to be accurate enough and stable enough that it can establish its own criteria for convergence. So, in your later example I have forced values for those options. Sometimes it requires fiddling, also because evalf/Int might also require high enough working precision to attain its target accuracy.

Unfortunately, I lost patience fiddling and threw in a scaling factor, to get the integrand to a nice range. It works, but muddies the question of what is really needed.

I have used unapply within the call to evalf(Int(...)) since I've found that all too often it is a useful way to prevent the numeric integrator's zealous approach to checking for discontinuities when presented an integrand in expression form. I didn't check whether it was completly necessary here.

4) I didn't accomodate the case that the numeric integration ever fails to produce a numeric value. The proc3 could (and probably should) test that the numeric integration has returned a numeric value. If it hasn't then it your luck depends on which minimizer you're using, and how it handles ever getting a nonnumeric value for the objective. Some won't handle the discontinuity that a default "large" fallback value can cause. Some won't handle a nonnumeric Float(undefined). DirectSearch handles occasional nonnumeric values from the objective better. 

5) Keep in mind that for the multivariate case Optimization is a local rather than a global optimization package. (The add-on package DirectSearch provides global optimizers.)

The attached worksheet runs pretty quickly. But I had to fiddle to get that.

Download MaplePrimes_Minimization_ac.mw

restart;

expr := y[1](t)*y[2](t)*(y[1](t)+y[2](t))^3:

frontend(diff, [expr, y[1](t)]);

                                  3                                        2
       y[2](t) (y[1](t) + y[2](t))  + 3 y[1](t) y[2](t) (y[1](t) + y[2](t))

Physics:-diff(expr, y[1](t));

                                  3                                        2
       y[2](t) (y[1](t) + y[2](t))  + 3 y[1](t) y[2](t) (y[1](t) + y[2](t))

subs(y1t=y[1](t),diff(subs(y[1](t)=y1t,expr),y1t));

                                  3                                        2
       y[2](t) (y[1](t) + y[2](t))  + 3 y[1](t) y[2](t) (y[1](t) + y[2](t))

thaw(diff(subs(y[1](t)=freeze(y[1](t)),expr),freeze(y[1](t))));

                                  3                                        2
       y[2](t) (y[1](t) + y[2](t))  + 3 y[1](t) y[2](t) (y[1](t) + y[2](t))

By "group" do you mean sort, or separate?

If you mean sort then you could use the sort command. If you mean separate then you could use the select (or selectremove command).

In any case, it would help if you explained how you wish to compare (for sorting) or discriminate (for selecting) between the eigenvalues.

Are they all purely real?

Here is an example of sorting a list of lists by the real value in each inner list's second entry.

L := [ ["SA",3], ["HF",2], ["JU",7], ["AK",1] ]:

sort( L, (a,b) -> a[2] < b[2] );

    [["AK", 1], ["HF", 2], ["SA", 3], ["JU", 7]]

sort( L, (a,b) -> a[2] > b[2] );

    [["JU", 7], ["SA", 3], ["HF", 2], ["AK", 1]]

If the second entries were complex-valued then you could also sort them by modulus or argument (or some combination, using and, etc).

The sort command has some powerful functionality, and I've only given a simple example. There are also matters like efficiency (eg. see the key option), ease-of-use, etc, which may or may not be important to your case.

sort( L, key = (a -> a[2]) );

    [["AK", 1], ["HF", 2], ["SA", 3], ["JU", 7]]

You might consider looking at the Help page for the sort command.

Here is a very simple example of separation according to a test on the second entry of each inner list. Again, you could make the selection procedure more complicated.

(L1,L2) := selectremove(a->type(a[2],odd), L):

L1;

      [["SA", 3], ["JU", 7], ["AK", 1]]

L2;

                [["HF", 2]]

If by "group" you meant something more complicated then you should tell us what you mean in detail. It might be that you're after functionality attainable using a command from the ListTools package (eg, its Classify, or Group commands, etc).

Check your syntax. It looks like some of your bracketed terms might accidentally be entered as part of function calls rather than as parts of any multiplication.

For example, it might be that you have the function call,
    UA_C(T_c-T_C)
while what you intended was the multiplication,
    UA_C*(T_c-T_C)

Otherwise, you won't be able to eliminate T_c, because it's part of an abstract function call.

This syntax issue might be a problem in more than one place (eg, also on UA_H(...) at least...).

We can't tell for sure because you have only provided us with an image of your code rather than actual code. You can upload and attach a Document using the green up-arrow in the Mapleprimes editor's menubar.

Your condition that all the variables are positive integers violates the constraint. It is violated even if the values are all as small as possible, ie. they have a value of 1.

Positive_integer_ac.mw

Perhaps you meant this:

Maximize(5*x1+2*x2+7*x3+6*x4+x5+6*x6+8*x7+6*x8,
         {10*x1+9*x2+15*x3+3*x4+11*x5+6*x6+3*x7+4*x8<=22},
         assume = nonnegint);

    [56, [x1 = 0, x2 = 0, x3 = 0, x4 = 0, x5 = 0,
          x6 = 0, x7 = 7, x8 = 0] ]

If you state which solution you want (and what ranges for x and m) then you could adapt the rootfinding call appropriately.

The `plot` below could also be made more clear (filling in the gap). But you could also figure out how much accuracy you want.

The code has two ways to do the rootfinding (Calculus1:-Roots which utilizes fsolve's avoid option, and fsolve with its maxsols option which utilizes RootFinding:-NextZero).

Download dwson_m_x.mw

You can also do a similar thing for finding x as function of m. (It's actually easier and slightly quicker, avoids the gap, and the plot's axes could even be transposed).  dwson.mw

You could use an Empirical distribution or choose for this from RandomTools (or ProbabilityTable from the Statistics package).

I don't know whether you want individual (scalar) results, or lists, or Vectors. I don't know whether you want integers or floats. I don't know whether you'd prefer using Statistics or RandomTools, and I don't know whether you want easy ways to get just a few values or efficient ways to get many values.

So here are various ways.

Download empirical_ac1.mw

You might also consider throwing in additional arrows normal to the line whose slope is the linear objective c1*x1+2*x2 .

One nice thing to illustrate is that the maximum is attained by moving [x1,x2] as far as possible (within the feasible region) in the direction of the normal to the objective line.

Below, I translate the line (so that it passes through the optimial point, give the current c1 value) since that gives a visual cue.

There are all kinds of variations on doing this.

If you really want to get fancy you could animate by the rotation angle (and compute the effective c1 value on the fly from that), which would produce a more even visual experience.

Another finesse might be to have a chunk of frames for the special case that the line is parallel to a side of the feasible region. In that case the whole edge of the region is optimal, and could be briefly all colored in green. Having a chunk of constant frames would provide a visual pause.

Download LP_anim2.mw

The basics of showing the feasible region, objective line, and optimal point are not complicated. There are several straightforward approaches to that, depending on how clear you want it to be for a reader who does not already know the underlying math.

Naturally, the code gets longer as you add in normal lines, a complicated title, etc.

Eventually you might discover that it's easier to learn and use a little Maple language syntax than to try and use the context-menus (Clickable Math, right-panel) for everything.

But here are some ways, including a little more use of the context-menus. (There are, of course, many other ways, including doing it fully by language commands.)

Download maple_ac.mw

You could try changing the syntax to, say,

   evalf(Int((r,a)->P(r)*a, [0..1, 0..1])):

or,

   evalf(Int('P'(r)*a, [r=0..1, a=0..1]));

Do you see that when you changed from single-argument to two-argument you also changed the calling sequence? You changed it to an invalid mashup of operator and expression form.

Alternatively, you could use P(r)*a as the expression, but you'd first have to modify the defn of P so that it returned unevaluated if passed symbol r rather than a number. One of your attempts this way encountered what's known as premature evaluation, where P received nonnumeric r and was not set up to deal with that. For example,

P := proc(r)
   if not r::numeric then return 'procname'(r); end if;
   ...proceed as usual...   
end proc

I prefer this last approach.

But you cannot sensibly use P*a as the integrand, where P is a procedure and a is an expression in one of more of the variables of integration.

If you upload your actual data file as an attachment in a Comment on the Question then I can easily show you all three methods at work.

As a side note, procedure P could be far more efficient if you wrote it to not have to re-form the data every time it gets called. I'd prefer to have the data, to check, before re-writing it all. You could substitute the actual data in lieu of a dummy name in the proc, or you could do it like, say,
   unapply('CurveFitting:-ArrayInterpolation'(...),numeric)
where use is again made of uneval quotes.

It's difficult to be precise when you haven't shown us the details of the actual data.

But I'm curious, did you want to escape a backslash in "VAGRANTASP\Adam" ?

Your final output seems like it may contain "VAGRANTASP\\Adam" with an escaped backslash. But your 2D Input contains a piecewise that compares against "VAGRANTASP\Adam" instead. Is that mismatch an oversight?