@PaulNewton 

Everything that I know about regular expressions came from reading the help pages
?StringTools,Regular_Expressions, ?StringTools,RegMatch, and ?StringTools,RegSubs, so they can't be that "dark".

Here's a procedure that omits the true:

NumberAtEnd:= proc(S::string)
description 
    "Extract a parenthesized number, possibly containing periods, from the end of a string"
;
local r; 
    if StringTools:-RegMatch("\\(([0-9.]*)\\)$", S, r$2) then r else FAIL fi
end proc
:
NumberAtEnd(L1);
                             "2.13"

@acer Thank you. I thought that you might have something in mind with a custom embedded component, not necessarily Explore.

You wrote:

• There are a few more tricks possible that can reduce kernel/Library side memory use here, eg. Aliases instead of temporary rtables for data passed to the plotting commands, direct construction of final PLOT structures, etc.

I thought that that was what my code did. Do you see it differently? The only usage of any plotting commands is in the construction of the first frame. The frame-changing procedure P only writes 3 numbers directly into the existing Frame without reconstructing it.

• But I doubt any of that would help with a GUI memory clog on an embedded Plot Component.

Correct. My measures substantially reduce the execution time, especially the startup, but don't help with the GUI memory problem. And it reduces the memory allocation required for the kernel, but that was already fairly small anyway.

Is there any way to insert ssystem calls (say, after every 100 frames) to invoke the Java garbage collector? 

@dharr Thanks for pointing that out. I didn't read the text closely enough. My Answer is thus irrelevant to this Question.

@mmcdara It turns out, in this case, that the slowness is caused entirely by the presence of sqrt(89) (which is the only radical in the matrix). Replacing this with a variable is all that's needed to get a quick result. A much-easier-to-read initial matrix and final result can be obtained by noting that D__pile and E__c can be factored out of every matrix entry.

CodeTools:-Usage(
    length((MP1:= 
        eval(
            LinearAlgebra:-MatrixInverse(
                eval(KGff, sqrt(89)= sqrt89), 
                method= pseudo
            ),
            sqrt89= sqrt(89)
        )
    ))
);
memory used=52.29MiB, alloc change=0 bytes,
cpu time=469.00ms, real time=481.00ms, gc time=0ns
                             10767
CodeTools:-Usage(
    length((MP2:= 
        eval(
            LinearAlgebra:-MatrixInverse(
                eval(KGff, [sqrt(89)= sqrt89, D__pile= 1, E__c= 1]),  
                method= pseudo
            ).(D__pile*E__c)^(-1),
            sqrt89= sqrt(89)
        )
    ))
);
memory used=19.46MiB, alloc change=0 bytes, 
cpu time=172.00ms, real time=178.00ms, gc time=0ns
                              4167

@PaulNewton You can also get a grey box from the toolbar of the MaplePrimes editor. It's the last item in the 2nd-to-last group in the 2nd row. It looks like <>.

By the way, I was a big user of FoxPro 30 years ago, before Microsoft bought it.

@MANUTTM What format of table do you want? I mean, What should be the column headers and row labels?  Do you want a separate table for each value of k1?

@PhearunSeng Like this:

eqs:= ...exactly what you had...;
V:= indets(eqs, specindex(W)); #decision variables
Wsol:= solve(eqs, V);

@PhearunSeng Assign the output of LinearSolve to a variable, say sol:

sol:= <W>=~ LA:-LinearSolve(LA:-GenerateMatrix(eqs, [W]));

Then make the last command

eval[recurse]([W], [InputW[], seq(sol)])[];

@Oliveira Note that what you're calling a "path" is usually called a Hamiltonian circuit or Hamiltonian cycle.

@Manuparis The instructions that I gave pertain to an existing Maple 2-D plot of curves. That's what I thought you were asking about. But now I understand that you want to "digitize" an existing image from an external source. 

What is the file format of the image? Maple's ImageTools package might be able to help with that, but I suspect that some other software would be better for putting the graphic into numeric form.

I converted your Post into a Question. Please put questions in the Question section.

@acer A variation of your Answer having the benefit of avoiding an -> is

evalindets(x, specfunc(exp), eval, omega1= omega2);

Here are some Answers to your Q2 and Q3. You asked:

• Q2:-  What is a good way to handle different numbers of inputs to procedures (exported) here eg Proc1(a), Proc2(a,b), ....,                   ProcN(a1,...,aN)

Hmm, I don't see those procedures, nor does the given module have any exports. Perhaps this module is intended to be part of a larger module that you didn't post? Anyway, notice the change that I made to your two-parameter procedure in the overload. I changed its header from proc(A, B) to proc(A::_T2L, B::_T3L, $). That $ means that overload will reject that procedure and move onto the next one if the number of passed arguments is more than 2. If you use $, it must be at the end of the parameters.

• Q3:-    Would the package exports of the module be the procedures inside the Mydispatch? Or does all of MyModule sit inside the  package module?

MyModule does not have any exports; its only interaction with the outside world is through its ModuleApply. At the moment (not seeing the overall package), I see no reason to put the code of MyModule inside another module. But you can call it from any other module, or, indeed, from anywhere at all.

Since the final polynomial obtained by @acer compares favorably under various metrics to the one produced by you by hand, produced by me by hand, and produced by codegen:-optimize(..., tryhard) (which are all the same polynomial except for slight differences in the order that the variables appear), one may wonder why optimize didn't return it. There are various metrics in use in this thread. I'd guess that the two primary ones actually used for optimization (rather than just being measured for curiosity) are 

• Length: essentially order isomorphic to the number of characters in a displayed form of the polynomial. Good and essentially order-isomorphic approximations to this can be obtained by the commands length (built-in and extremely fast) and `simplify/size/size`, used by the important optimizing command simplify(..., size). The exact number of characters is returned by (length@String), which could also be used as a metric, but isn't used by any of the methods discussed so far in this thread. 
   
• Operation count (which I'll abbreviate as opcount): A count of the number of basic computational operations (mostly arithmetic and assignment) that are needed to evaluate the expression to a (one-word) number when the variables are given (one-word) numeric values. This is the metric more closely related to computational efficiency and the one used by codegen:-optimize(..., tryhard). It allows for the use of intermediary variables (used for repeated subexpressions). This metric can be obtained (exactly) by codegen:-cost.

You may have noticed from my Answer that I used these steps:

1. Extract the variables from the expression ex by using indets;
2. Convert ex to a procedure by using unapply;
3. Put that procedure through optimize, which returns a new-and-improved procedure;
4. Apply that new procedure to the original symbolic (i.e., non-numeric) variables.

I used step 4 in case you were truly interested in the displayed length of the expression; however, for those interested in computational efficiency (as measured by opcount), step 4 is a very bad idea. Here is (essentially) the optimized procedure returned by optimize. Since it uses meaningless names for the intermediary variables, I changed them to meaningful ones; and I used modern sleek syntax (which requires 1D input):

new_ex:= (G1, G2, G3, G4, G5, G6, G7, G8, P2, P3, P5, P6)->
local G458:= G4 + G5 + G8,  G34578:= G3 + G458 + G7;
    G34578*P2 + (G1 + G34578)*P5 + (P3 + P6)*(G1 + G2 + G458 + G6)
:

You can easily obtain the opcount by eye---11 additions, 2 multiplications, 2 assignments, 2 (local) storage---which is also what codegen:-cost(new_ex) will say. This is significantly better than if step 4 is used, that result having 17 additions and 3 multiplications.

@666 jvbasha A negative number raised to a fractional or "decimal" power is always nonreal. I don't know if the derivative that you raise to the power n-1 is ever negative, but if it is, there will be a problem. I doubt that Maple's numeric PDE solver could be made to work with nonreal values.