I'd just write two different classes for permutations. The underlying bit-twiddling is different but various high-level structures can be inherited to both. At the end of the day the permutation should be defined how it acts on an ordered container, regardless of whether the container is indexed starting at 0 or 1. Anything that just depends on this action can be shared between the two classes. And yes, different _repr_ so you don't get confused all the time. And no coercion between the two permutation types, if you want to multiply a 0- and a 1-based permutation then you have to convert explicitly to your favorite representation.
On Saturday, September 6, 2014 8:13:58 AM UTC+1, Nathann Cohen wrote: > > > So how about making it explicit, have separate Permutation and > Permutation0 (instead of tuple vs list). They can share most of the > backend, its just a slightly different set that they operate on. In Code, > you just call sigma = Permutation0(sigma) on user input in the beginning to > convert it to your desired presentation if you depend on the actual > integers. > > This would be cool, but how do we write the code afterwards ? What are > the objects returned by Permutation1 and Permutation0 ? The functions > of this class have been written with a standard in mind, and if you > let it deal with 0-based permutations and 1-based ones some functions > will break. > > And if we make 1-based permutations be 0-based permutations with a > diferent __repr__, a different __call__ and a different __getitem__ we > will run into problem too.. How could we make this strategy work ? > > Nathann > -- 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/d/optout.
