HI Anne and Travis, Thanks for your replies.
With my display() suggestions I was talking about a general mechanism rather than just for the example I gave of partitions. Either passing a flag to _repr_, as Anne suggested, or having a global way of setting output formats as Travis suggested would work. Of course, if no one else in the sage community wants such a thing then I should pull my head in:) > Do you think that changing these functions so that they take cells as >> input is a good idea or bad idea? >> >> I can see your point for wanting to use tuples. I personally have some >> private code which uses >> these methods a bit and it would hence be useful if some appropriate >> warning would be given >> if code assumes as input two integers, so that this code will be easy to >> debug! >> > > Best idea to me would be to allow both inputs, but since we don't have > polymorphism, you'd have to give default arguments of None to the current > inputs, add an **options where your input would be something like > `cell=(x,y)`, and check to see if that option has been passed in first. > This way it would retain all backwards compatibility, but still be useful > to you. > I like the named argument suggestion except that it having routines parse input is, I think, generally a bad idea as it leads to slower code. Currently most of these routines actually accept as input EITHER two integers, i and j say, or a cell=(i,j) and then they have to decide what to do with it. This doesn't create much overhead as managed via try-expect. Still, I see what I can manage along these lines. Are there any methods/members/attributes for PartitionTuple which > Partition should not have/do? Because if not, then I think it should be > subclassed and you'll need to do things like this for methods you are > overriding: > > def hook_length(self, i, j): > return PartitionTuple.hook_length(self, (i, j, 1)) > I haven't come across anything yet which PartitionTuples can do but Partitions can't. I did act an extra methods level() and components() to partitions but apart from this nothing has changed so far. The partition tuple patch (#13072) is already too large so I won't do anything about this now, but once it is merged if no one else is "fixing" partitions I'll volunteer to do this. Also, I don't think that there are any issues like the one above as if Partition was a subclass of PartitionTuple then methods like these would simply over ride those of PartitionTuple. Incidentally, after much agonising, I made the cell indexes of partition tuples the opposite of what you have above: it's (component, row, col) and they are all zero based. For example, the cells of mu=PartitionTulpe([2,1],[3],[1^2]) are (0,0,0), (0,0,1), (0,1,0), (1,0,0), (1,0,1), (1,0,2), (2,0,0), (2,1,0) As you did above, in the literature the component is usually the last element of these tuples but as mu[0]==Partition([2,1]) etc I decided that it more was more intuitive to put the component first. Of course, this counter-intuitive for partitions, but for partitions there will be no change so this shouldn't cause any confusion. Andrew -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/bNrqsJSG6CAJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
