@Bohdan The corresponding Maple command is LinearAlgebra:-LinearSolve.

Yes, solving A.X = B (Maple command LinearSolve(A, B)) is almost always better than computing A^(-1).B, even for purely numeric matrices.

The first link that you posted discusses a10x10 matrix with only one variable. The 2nd link is a 21x21 matrix with only 6 variables. Yours is 27x27 with essentially 243 variables. Even using LinearSolve with your symbolic matrix is totally out of the question. If you give almost all of your variables numeric values, it may be possible.

Let me emphasize another point again: The inverse itself---regardless of the method used to compute it---is enormously complex. There's no possible "efficiency" that can change that fact. This situation is completely different from a problem that has a solution that's simple in its final form, yet it's "merely" the algorithm that takes a long time. An example of such a problem is the famous Traveling Salesman Problem (look up in Wikipedia). (I put "merely" in quotes because there's a million-dollar prize offered for finding an efficient algorithm even for that (or for proving that no such algorithm is possible).)

Using my best-case estimate, the inverse is 1.7x10^10 times more complicated than the 8x8 case. Therefore, a single entry of the inverse is 1.7x10^10 / 27^2 = 2.4x10^7 times more complicated than the 8x8 case. There's no "sneaky" way to do this symbolically by computing it one entry at a time.

@Bohdan Here's an example of a simple pattern that could be inverted: Suppose that every one of the currently nonzero entries was an integer (possibly different), except for a handful that were x, so that the matrix has the one variable, x.

But the main point that I'm trying to convey to you is this: It's not worth your time, my time, or anyone else's to give any further consideration to inverting this matrix. Forget about it.

In my Reply above this one, I added a best-case estimate that the 27x27 will take a factor of 1.7x10^10 as much time as the 8x8.

@bikramphy I deleted your Question that simply added "Petrov type O" to this Question because it is too similar to this Question to merit its own thread. Please use this thread to post the amended question.

@Bohdan I said "very special", not "very spatial". Anyway, the problem seems so enormous from first impression that I doubt that any serious computational mathematician would bother taking the time to even consider the possibilities of the patterning.

The pattern that you've described is not simple in a way that helps. Your matrix has 3^5 = 243 distinct nonzero symbolic entries. From a computational persepctive, those might as well be 243 distinct variables.

Here's a best-case estimate comparing the 27x27 problem with the 8x8:

evalf(GAMMA(1 + sqrt(243))/GAMMA(1 + sqrt(32))) = 1.7x10^10.

@DoingMath2018 

At z = -1, the sum diverges (unconditionally) to -infinity. And also limit(ln(1+z), z= -1) = -infinity, regardless of direction. So Maple's response using assuming abs(x) <= 1 seems sensible to me.

@Bohdan To get a rough estimate of those orders of magnitude: 27! / 8! = 2.7x10^23. So, if the 8x8 took 2 hours, then the 27x27 may take 5.4x10^23 hours (far longer than the age of the Universe) using the same algorithm, unless perhaps there's some very simple pattern to the entries in addition to all those zeros.

@Bohdan 

Let's consider the enormity of the problem of inverting a 27x27 symbolic matrix: Suppose that you have a 27x27 matrix each entry of which is a single distinct variable (so there are 27^2 different variables). Then each entry of the inverse is a rational function. The denominators are all the same polynomial, which has 27! = 10888869450418352160768000000 = 1.09x10^28 terms, each term having 27 factors. There are 27^2 different numerators, each being a polynomial with 26! terms, each term having 26 factors. Now, obviously, there's not enough memory in all the computers in the whole world--put together--to represent that. So, regardless of the "way" or algorithm used, it's impossible to compute if for no other reason than the size of the result, which is a mathematical fact that's not changeable.

Now, if your matrix has some **very special** pattern (instead of 27^2 different variables) and a lot of zeros, maybe something is possible, but I doubt that it'd be worth the effort.

@Bohdan Please post the data file, or at least a few lines of it (including the first line). Also, the code that Joe and I posted makes no attempt to skip over header lines (if there are any).

@PhD_Wallyson Your M is a 4x4 matrix, but plot_mode is implicitly hard-coded to expect that M will have 12 columns. This is because it contains this 12-vector:

<a[1], b[1], c[1], d[1], a[2], b[2], c[2], d[2], a[3], b[3], c[3], d[3]>

@Scot Gould You wrote:

• I'm not sure it is worth much time in reading more about the ordering of sets given that "This order could be changed in future versions of Maple, and/or objects could be represented in a different way in future versions. You should not assume that sets will be maintained in any particular order."

Although---as that help-page quote suggests---the set order is not "carved in stone", set order is still a very useful thing: It ensures that (for sets of immutable objects) when a computation starting with restart is re-run with the same version of Maple (even on a different computer), the sets will be ordered the same way. This is much better than set order's predecessor: Sets used to be ordered by the memory addresses of their elements, which is ephemeral.

While I don't think that it's important for the average user to know the details of the set order, it is useful to know that there is a fixed set order (for sets of immutable of objects).

@Carl Love And here are the results of the experiment:

KeyLE:= (k1, k2)->
local r:= 0;
   if [k1,k2]::listlist then #try lex order of lists
       k1=k2 or `or`((do until k1[++r] <> k2[r]), thisproc(k1[r], k2[r]))
   else 
       try #numeric or string order 
           if (r:= evalb(k1 <= k2))::truefalse then r else error fi
       catch: evalb(k1 = {k1,k2}[1]) #set order (guaranteed to work)
       end try   
   fi
:
KeyLE_lame:= (k1, k2)-> 
    try if (local r:= evalb(k1 <= k2))::truefalse then r else error fi
    catch: evalb(k1 = {k1,k2}[1])
    end try
:
#Test list to sort:
S:= [seq]([seq](i), i= Iterator:-CartesianProduct([0, -1., 1.] $ 2))
: 
S1:= sort(S, 'key'= (x-> x));
    S1 := [[0, 0], [0, -1.], [0, 1.], [-1., 0], [-1., -1.], 
      [-1., 1.], [1., 0], [1., -1.], [1., 1.]]

S2:= sort(S, 'setorder');
    S2 := [[0, 0], [0, -1.], [0, 1.], [-1., 0], [-1., -1.],
      [-1., 1.], [1., 0], [1., -1.], [1., 1.]]  

S3:= sort(S, KeyLE_lame); 
    S3 := [[0, 0], [0, -1.], [0, 1.], [-1., 0], [-1., -1.],
      [-1., 1.], [1., 0], [1., -1.], [1., 1.]]  

S4:= sort(S, KeyLE);
   S4 := [[-1., -1.], [-1., 0], [-1., 1.], [0, -1.], [0, 0], 
     [0, 1.], [1., -1.], [1., 0], [1., 1.]]

nops({S1,S2,S3});
                               1
evalb(S1 = S4);
                             false

So lexicographic order of the lists doesn't have precedence over set order. Nonetheless, my idea of having key return a list is still useful, as shown in my Answer. If all the lists have the same number of entries, and the items in each list position collate as desired, then set order and lexicographic order will be the same. In particular, realcons fields in the list should be evalf'd to floats because set order puts integers before floats.

This is probably obvious, but one reason why the lexicographic order of lists is more desirable is that it makes keyed sort distribute over Cartesian products in the sense that

sort(A X B, key= (x-> x)) = sort(A, key= (x-> x)) X sort(B, key= (x-> x)),

where A and B are lists, and X is the Cartesian product operator.

@janhardo There is no formal structure for files with extension .mpl; you could just as well use .txt.

@David Sycamore My code was skipping the cases where the odd number appended to the right of the digit sum has leading zeros.

@Joe Riel I'm guessing (or perhaps I should say "hoping") that the builtin code of sort totally orders the keys the same way that they're ordered by this "<=" procedure:

KeyLE:= (k1, k2)->
local r:= 0;
   if [k1,k2]::listlist then #try lex order of lists
       k1=k2 or `or`((do until k1[++r] <> k2[r]), thisproc(k1[r], k2[r]))
   else
       try #numeric or string order 
           if (r:= evalb(k1 <= k2))::truefalse then r else error fi
       catch: evalb(k1 = {k1,k2}[1]) #set order (guaranteed to work)
       end try
   fi
:

Specifically, my hope is that lexicographic order of lists of the same length takes precedence over set order. Here is the *lame* alternative:

KeyLE_lame:= (k1, k2)->
    try if (local r:= evalb(k1 <= k2))::truefalse then r else error fi
    catch: evalb(k1 = {k1,k2}[1])
    end try
:

I'll run some experiments to discriminate these tomorrow.

@Anthrazit Definitely I would choose JSON over XML for this purpose. The "ML" in XML stands for "markup language", meaning that it's more oriented towards visual display than data storage.