Hey Andrew,
Here's my 2 cents.
> 1. When I am doing lot of calculations I often generate a large amount of
> output and, consequently, I like this output to be as concise and readable
> as possible. Most of the _repr_ and _str_ methods
> > do not achieve this.
> >
> > What do people think about introducing a display() method which returns
> compact readable output? For example, I have the following implemented in
> my local version of sage:
> >
> > sage: Partition([8,8,8,5,4,4,4,2,2,1,1,1,1,1,1,1,1,1,1]).display()
> > (8^3,5,4^3,2^2,1^10)
> >
> > I am not particularly fussed what the method is called (currently, I am
> actually using compact_repr), but I do want such a method. To start with,
> it could be implemented fairly high up in the class
> > hierarchy and just default to _repr_.
> >
> > As a related side issue, my understanding is tht _repr_ is suppose
> return a string which can be used to recreate the object, which is often
> really useful as it allows you to cut and paste the output
> > back into sage. However, this seems to be rarely done in sage.
>
> This is fine with me. Alternatively you could have
>
> def _repr_(compact = False):
>
> If compact is False then the usual output is used. If compact is True your
> shorthand could be
> used. I think this is also called the frequency notation in Macdonald's
> book. This might be
> another name for it.
>
My understanding of _repr_() is it needs to give you all of the data you
need to recreate the object, not a copy/paste version because it needs to
tell you what it is (which can be a lot easier than calling typeof() on
your object). As for your idea on output, see my thoughts on the latex (q5).
> > 4. Although very picturesque, the names corners() and outside_corners()
> for partitions seem wrong to me. What do people think of changing them to
> removable_cells and addable_cells, respectively?
>
> That would be fine with me. It would have to be globally changed however.
>
Fulton uses the terminology of (outside) corners in his book Young
Tableaux, and I'm fairly certain I saw it used some place else. In this
case, I'm not opposed to multiple names for the same function (python is
slick about how you can do this too, `removable_cells = outside_corners`).
> > 5. The latex method for partitions has recently changed so that it
> returns latex code for the diagram of the partition. Although useful, I
> think this function should called something like
> > latex_diagram. I would prefer that the latex() method for a partition
> return something like "8^3,5,4^3,2^2,1^{10}" as when I generate latex code
> I am typically printing out reams of data to try and
> > spot a pattern in the combinatorics (cf. #1 above).
>
> For pictures in latex, I usually prefer the Ferrers diagram notation. This
> is also useful for
> the upcoming rigged configuration code. But we could indeed have two
> methods. I think Travis Scrimshaw
> (my student) is the person who recently changed this.
>
Yes, I was the one who changed this (in ticket #12314), and I do use it in
my RC code. However I think the best way to implement this would be to add
a method set_latex_options(output="output_type") where we then interpret
this in the latex output (similar to how DiGraph does things, although it
should be with less fragmented code). Thus you would do something like
sage: P = Partition([3,2,2,1])
sage: P.set_latex_options(output="exponent")
sage: latex(P)
3^{1} 2^{2} 1^{1}
Perhaps we might need to do this with a more category framework approach
and have it be something set in a parent/category (assuming this is a good
concept)? Similarly I think we should do something more global with the
repr too depending upon how the user wants to view partitions (either by
convention/output style/etc.).
> > 6. There are quite a few methods for partitions which, morally, take a
> cell as input but which in practice take or accept two integers are input
> (for example, arm_length, leg_length, hook_length,
> > content), for compatibility with the corresponding methods for the
> PartitionTuple class it would be better if these were changed so that they
> took a cell, or tuple, as input. The idea being that this
> > makes it possible to write code which works for partitions and partition
> tuples simultaneously.
> >
> > 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.
> > 7. In writing the PartitionTuple class I should really have started by
> putting Partitions into the parent/element and category frameworks, but I
> didn't. Now that (I think) I have worked out how this
> > works, I could go back and do this. Currently Partitions and
> PartitionTuples are implemented as two parallel classes with PartitionTuple
> pretending that a Partition is a 1-tuple of partitions. Every
> > method for PartitionTuples is also a method for Partitions but not visa
> versa. For some of these methods the code for the two classes is identical,
> but for some it is different, and sometimes quite
> > different, largely because as in #6 cells for partitions are 2-tuples
> whereas cells for partition tuples are 3-tuples.
>
> I think it would be a good idea to put partitions in the category
> framework. Some people might
> have already started doing so (Jason?, Florent?).
>
> > I wrote the PartitionTuple code so that it was independent of and, in
> particular, didn't change the partition code but it might be more natural
> to have the Partition class as a subclass of the
> > PartitionTuple class. I can't see any reason why this would make
> partitions less efficient, but there are many others with more experience
> here, and maintenance of the two classes might be slightly
> > easier. This said, I have no strong feelings either way about this (and
> it is certainly less work for me to leave the classes as they are!).
> Similar comments apply to the Tableau and TableauTuple classes.
>
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))
In order to keep backwards compatibility and because the input is more
natural (to me at least). You'd also have to handle options accordingly if
you follow my previous advice. However converting to this should not be too
much work.
This should be (slightly) slower because of the additional function call
(at the very least because it needs to create a new tuple, but this should
be marginal), however I don't know if Python does anything to optimize
these super-calls (I doubt it does considering its structure). Also I'm
fairly certain there's not any real penalty for virtual function calls.
Best,
Travis
--
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/-/JU3yjM0H8xcJ.
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.
