@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.

@Joe Riel I think that you realize this already, but I'll mention it for Scot's and others' benefit: keyed sorts use setorder of the keys as a last resort if the keys are incomparable numerically or as strings. It may then try lexicographic order of lists (not sure). Only if the keys are otherwise incomparable does it use setorder.^[*1] For example,

S:= {evalf(-Pi), 0, evalf(Pi+1)}:
sort([S[]], 'key'= (x-> x));
                 [-3.141592654, 0, 4.141592654]

sort([S[]], 'setorder');
                 [0, -3.141592654, 4.141592654]

[*1] These statements are guesses based on some *small* amount of experimentation on my part. Since sort is built-in, I can't read its code and say for sure.

@Scot Gould You wrote:

• If I understand what you wrote, sort uses the value from first entry of a row label's list that it obtains from the key function to order the row labels, but if the two values from the two lists are equal, it uses the values from the second entry to compare. Yes?

Yes.

• This is exactly what I want it to do.

Yes, of course; that's why I posted it.

• However, in looking over examples in Help, I saw only one example of using 'key' so I'm not exactly sure how one would be able to know sort will work with a list of entries in the keys. 

It's my own discovery.

• Unless you object, I will suggest Maple add this example to the list of examples in both the "sort" help page and the "DataFrame/sort" page.

That's a good suggestion. I don't object.