Hi Andrew,
Here are a couple of answers, I feel competent enough to answer:
> 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.
> 2. We currently have a nested series of classes for tableaux, one branch of
> which is
> Tableaux > SemistandardTableaux > StandardTableaux > StandardTableaux_n >
> StandardTableaux_partition
>
> My question is, does there exist an efficient way of making use of the class
> hierarchy to construct new elements whenever there is a nested structure of
> classes like this?
You answered this yourself.
> 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.
> 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.
> 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!
> As one example, with the patches currently in the queue it wouldn't be hard
> to implement the crystal graphs of the irreducible representations of the
> (quantised) affine special linear groups -- by
> this I mean return a graph with vertices being certain (infinite) sets of
> partition tuples and certain labelled edges and with all of the usual crystal
> data, but I am not sure how easy it would be to
> put this into the crystal framework already implemented in sage. (I could do
> this if people were interested, although I'd appreciate some pointers as to
> what needs to be done to turns this data into a
> proper sage crystal.) As some of the partition methods currently take i,j as
> input, rather than a cell (i,j), the level one case would probably have to be
> treated separately.
Have a look at
../sage/categories/crystals.py
for a general description and methods to be implemented.
There is also a sample crystal implementation in
../sage/categories/examples/crystals.py
In principle we have a model for all highest weight crystals in sage now in the
patch
trac_12251-littelmann-as.patch
in the sage-combinat queue.
> 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.
I let others comment on this!
Best,
Anne
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
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.
