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

I cannot duplicate your error in Maple 2020.1, and reading through your sys, I don't see how it's possible that you got that error in an earlier version of Maple. Your sys appears to be manifestly an explicit first-order system, so it doesn't need to be converted to one. So, are you sure that you got that specific error message using exactly the code shown in your worksheet? Please re-execute and confirm.

I get the error "initial Newton iteration not converging". That can usually be corrected by using a continuation parameter. I see that you mentioned continuation in a code comment.

@Anthrazit My shared kernel idea was based on a false impression of what you wanted. After reading your Reply to Tom, I realized that what you want is a database, something like your own version of Maple's ScientificConstants package. Mac Dude's Reply to your Reply outlines a potential solution. You should leverage Maple's Records as much as possible.

@Joe Riel I don't know if this is significantly more efficient, but I like it better (Maple 2019 or later required):

fd:= FileTools:-Text:-Open("data.csv"):
A:= Array([while (line:= readline(fd)) <> 0 do [parse(line)] od]);
fclose(fd);

Like your solution, mine supposes that each line contains the same number of entries, none of which are lists.

@Bohdan I'm guessing that your indexed entries are actually stored in the external file as strings, enclosed in double quotes. In that case, use datatype= anything. Let's say that you've successfully imported the file to a Maple matrix named M. We need to convert those strings to algebraic expressions. To do that, use

M1:= subsindets[flat](M, string, parse);

I just saw that you said "length exceeds error". The message "Length exceeds...." is not an error or even a warning. It's just a message that's shown instead of the actual output. It's only shown after that output has been computed in its entirety without error. That output still remains programmatically accessible.