Thanks for your idea, which, I must admit, I have already considered myself. But, so far, I have not used it because I very often copy-paste Maple code snippets back and forth in my programs, so you can imagine the mess which that could result in if I forget what is currently on my clipboard. Anyway, I still find it very hard to understand that the tabbing problem have not been caught in any testing process at MapleSoft prior to the release of Maple 11. But, of course, I am only here repeating my earlier expressed frustrations.

Update: The 'but...'-part of this post is no longer relevant as Joe Riel has now broken the lines that were too long to be properly displayed. Very interesting reading, but, unfortunately, the longer code lines of yours are hidden behind the right column of "Recent comments", etc., if viewed in a resolution of 1024x768 (I guess that it is me being a little "altmodisch", technologically speaking).

Actually, I did consider using evalb() for the very same reason that you describe. But as it worked without I thought I would just stick to the shorter version. You see, in the field of programming I am a self-taught person having no formal education, so unlike you and the other Maple masters, I suppose, some of the finer issues of programming, like evaluation rules, are often quite novel to me.

Thanks for your improved procedure. I wrote my procedure the way I did because I thought that

evalindets(L1-L2,0,x -> NULL)[1]

or in your case

subs(0=NULL,L1-L2)[1]

which is ill-defined for L1 = L2 would cause problems if evaluated. But I suppose the reason why your procedure works is that Maple does not need to evaluate this expression if L1 = L2 evaluates true because the boolean operator is an 'or'. Indeed, interchanging the two boolean expressions does produce the error "invalid subscript selector".

I have obtained the following general solution, I believe, to the problem of sorting a list of lists (of equal lengths) of arbitrary integers:

sortLists := proc(L1::'list'(integer),L2::'list'(integer))
   `if`(L1 = L2,true,evalindets(L1-L2,0,x -> NULL)[1] < 0)
end proc:
sort(L,sortLists);

Thanks a lot, Jacques!

Thanks a lot, Jacques!

I have realized that my code above does not, as I would expect, give zero for expressions like

Simplify(c[1] . c[2] + c[2] . c[1]);
Simplify(C[1] . C[2] + C[2] . C[1]);

I do not yet understand that. Defining your operators J by

J := Matrix(N,N,(i,j) -> I*(C[i] . c[j] - C[j] . c[i]));

I get the same squares as you do for expressions like

Simplify(J[1,2] . J[2,1]);

This problem, though, is probably related to the above one. Maybe someone else can help us out here.

I have realized that my code above does not, as I would expect, give zero for expressions like

Simplify(c[1] . c[2] + c[2] . c[1]);
Simplify(C[1] . C[2] + C[2] . C[1]);

I do not yet understand that. Defining your operators J by

J := Matrix(N,N,(i,j) -> I*(C[i] . c[j] - C[j] . c[i]));

I get the same squares as you do for expressions like

Simplify(J[1,2] . J[2,1]);

This problem, though, is probably related to the above one. Maybe someone else can help us out here.

Thanks again for the suggestion of yours. However, as you mention yourself, the procedure seems somewhat complex. And even though it treats list of lists of various lengths, as does also the code by Robert Israel, and it does not use sort(), these issues were not the intention of the originally posed problem of mine.

I have just written my first code using the Physics package, setting up, I believe, your operators and your rules as follows (where N equals 2 just for reasons of simplicity):

N := 2:
Setup(
   quantumoperators = {seq(c[i],i=1..N),seq(C[i],i=1..N)},
   algebrarules = {
      %AntiCommutator(c[i],C[j]) = KroneckerDelta[i,j],
      %AntiCommutator(c[i],c[j]) = 0,
      %AntiCommutator(C[i],C[j]) = 0
   }
);

Do we agree to this point? If affirmative, could you show me an example of your products of operators?

I have just written my first code using the Physics package, setting up, I believe, your operators and your rules as follows (where N equals 2 just for reasons of simplicity):

N := 2:
Setup(
   quantumoperators = {seq(c[i],i=1..N),seq(C[i],i=1..N)},
   algebrarules = {
      %AntiCommutator(c[i],C[j]) = KroneckerDelta[i,j],
      %AntiCommutator(c[i],c[j]) = 0,
      %AntiCommutator(C[i],C[j]) = 0
   }
);

Do we agree to this point? If affirmative, could you show me an example of your products of operators?

Could you upload the code which produces your display problem?

Thanks a lot for the apparently extensive work you have done on this problem of mine. However, please forgive me for saying so, I do not think that it represents a simpler solution to the problem than mine does.

Thanks for your cleverly designed code which is both cleaner and faster than my code is. I am happy to read that you too have been unable to find any built-in functionality (something like "lexicographic ordering for integers") because that tells me that I have not overlooked something embarrasing simple. You second suggestion is actually quite useful to me if, as seems rather reasonable, I disallow spacetime dimensionalities (in the package "SpaceTime" on which I am working) to exceed 255. Even for string/M-theory 255 spacetime dimensions should be sufficient, but who knows what those immensely mathematically gifted, but also, so it seems, at the same time increasingly out of contact with physical reality, guys in string/M-theory cook up next?! I cannot resist here quoting the famous put-down by Wolfgang Pauli concerning string-theory: "It's not even wrong."