> The reason why we need(ed) a separate core class is that for example > otherwise > it would not be possible or easy to implement the action of the affine > symmetric group > on (k+1)-cores. > > Of course, one can ask whether a given partition is an n-core and that > method > should live in Partitions, but the moment there are operations that only > make > sense on the set of n-cores, it seems necessary to implement a separate > class. >
I agree, although I'd prefer it to be a subclass. However this can be somewhat tricky (see beow). > > In fact, since Travis brought up the issue about a possible class for > k-bounded > partitions. I have some currently private code on some new methods on > k-bounded partitions that I think make most sense inside a class of > k-bounded > partitions, but of course I could also put them straight into Partitions. > What should I do? > > I'd want this to be a subclass since it looks like a partition and quacks like a partition, but it can also do tricks using its different colored feathers. However the problem then becomes when we apply an operation as a partition, we might leave the k-bounded world, so we need to change our return type. The natural thing (IMO) to do at this point would be to return the class and parent which fits our object in general, unless we want to do checks everytime we call this object. On the other hand, we have methods which always return our special type when starting from our special type (ex. take the transpose of a k-core), so do we convert the object after calling the general method or re-implement the method? One way to get around these things is to have the class be completely separate and have conversion functions when needed, which is what's currently done for cores. This has the added benefit of having the user explicitly do the conversions, so there are less surprises, but this separates us from what it is specializing. IDK, at the end of the day (and this long-winded response), I think subclass is best since it links the objects and it is a partition (at least in the case of k-bounded partitions) that just satisfies additional constraints which allows it extra methods. Also one can think of the k in k-core as an extra argument to the methods such as to_bounded_partition(). Best, Travis -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
