Hello! While trying to do computations in symmetric group algebras today, I was shocked by the fact that Sage uses the convention that a product \pi \psi of two permutations \pi and \psi is the permutation that applies \pi first and \psi later. In my opinion, this convention is highly nonstandard (I only saw it in GAP and in Herstein's older books; nowadays most mathematicians use the opposite convention without even mentioning it, and even Herstein stopped pushing the other way) and does not match the fact that permutations, like any functions, are applied to elements from the left in Sage (as opposed to GAP, which at least is consequent in that permutations act from the right).
This *can* be defended as a convention, but I see every reason to call it a bug. I spent a year or more using Sage, multiplying permutations among other things, and never noticed that the results I was getting did not mean what I supposed them to mean. (Working with the wrong operation order only becomes visible in S_3 and higher, and many properties of the symmetric group algebra are independent of the order -- like any group algebra, it is isomorphic to its opposite --, so one only gets bitten if one works with specific elements, like the Young symmetrizers; but for this reason it's particularly hard to notice that something is going wrong!) There is a further issue lurking in the background here. It *is* possible to make Sage use the standard convention (first \psi, then \pi), namely by setting a global variable (see http://trac.sagemath.org/sage_trac/ticket/14885 for details). Unfortunately, this requires knowing of the existence of this variable; apparently, some of the coders did not, and so a method in dyck_word.py seemingly completely unrelated to permutations (it only uses permutations in its implementation) breaks when this global variable is set. With no offense, I believe the only reason why this doesn't happen more often is that permutations are multiplied surprisingly rarely in Sage code (maybe for this reason?). In order to use products of permutations reliably in a method, one has to distinguish cases depending on this global variable! I've even seen the variable set to the standard value at the beginning of a method, and then reset back to what it was at the end. I thought we had Python to avoid having to hack like that. The main reason I'm posting this here is to sound out how many people see this as a problem like I do, and what solutions would be favored. I am not exactly a seasoned developer, so the way I see to solve the problems might be somewhat crude: 1) Switch the convention to the standard one, and remove the global variable. For those who want to use the GAP convention, add an OppositeAlgebra constructor/factory/class/whatever (I have to admit I don't understand Categories well enough to do that part, but if we can define dual bases we surely can define opposite algebras). 2) Fix the methods that rely on the convention being nonstandard. My experiments (breaking the __mul__ function on Permutations, and subsequently running doctests) show that the number of methods using products of permutations is rather modest (I made #14883 and #14884 to reduce it even further); however, it can be argued that I am counting doctests rather than methods... 3) Splatter warnings all over permutations, permutation groups, and symmetric group algebra code in the hope of waking up the users. Unfortunately, it doesn't seem like deprecation warnings can be used here, so there will be some rude awakenings. Nathann Cohen suggests a warning that is spat out the first time a product of permutations is being called; I hope this can be done in a way that does not break doctests. Any other ideas how to make things noticed? Is this too barbarous a solution? Is the problem not much of a problem? Best regards, Darij -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
