Hi Simon, > > Partition and PartitionTuple are not closely related. They are in fact > *totally* > different: >
There are two quite different and quite valid comparisons here: mathematical and implementation. The main point that I was making is mathematical. Of course, you are saying tht if they are closely related mathematically then their implements should be too. I don't disagee. > > > In terms of implementation, this was discussed a ittle on sage-combinat. > > The general feeling was that the implementation of PartitonTuple should > not > > compromise the Partition class because partitions are in so many places. > To > > avoid code duplication I would have liked to have both classes inherit > from > > a common super class (but still with the behaviour above that you don't > > like) > > You misunderstood (and I guess Volker misunderstood, too). > Actually, I think that I understood you and that you misunderstood me! :) As I said, when I was writing this patch I suggested that Partition should be a subclass of PartitionTuple. However, I misremembered the discssuion: people were not so much against the idea (but nor were they in favour of it). The main problem was that at that time the Partition class had not been moved over to the category framework. Given the size of the patch I already had I didn't want to go there -- see [sage-combinat discusson on PartitionTuples]<https://groups.google.com/forum/#!searchin/sage-combinat-devel/partitiontuple/sage-combinat-devel/5pL9A8nVQ5c/8zppu4-C1LUJ>if you're interested > > > They have nothing in common, except that they both inherit from > CombinatorialObject. > As I said, mathematically this is simply not true. In terms of the code this is not true either: there are a lot of common functions and hence a lot of duplication, which is bad. This was why I suggested that Partition should be a subclass of PartitionTuple. The code would certainly be better and this issue would disappear if the code were reorganised and Partition was made a subclass -- at the same time the underlying data structure could be changed to using ClonableArray/ClonableIntArray which would be faster. There has been recent discussion about doing something like this with the various tableaux classes. On the other hand, if some one is going to do this then they need to think about the best way to cover skew, composition, partition and parition-tuple shaped variants. At the moment there is a reasonable amount of duplicated code between these different variants. Cheers, Andrew -- 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.
