#20564: KleshchevPartitions
-------------------------------------+-------------------------------------
Reporter: andrew.mathas | Owner: andrew.mathas
Type: enhancement | Status: new
Priority: major | Milestone: sage-7.2
Component: combinatorics | Resolution:
Keywords: Kleshchev | Merged in:
partition tuples | Reviewers:
Authors: Andrew Mathas | Work issues:
Report Upstream: N/A | Commit:
Branch: | 4acb3a372215ad4cf045a989551a2c75b3988ea2
public/combinat/kleshchev_partitoins-20564| Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by tscrim):
Replying to [comment:17 andrew.mathas]:
> Thanks for this Travis!
>
> Replying to [comment:16 tscrim]:
> > I've done the first round of fusing the two implementations, and with
your version of (co)normal/good cells, I was not getting a crystal
structure. I changed things around so that they matched Kleshchev's
article for the definition of (co)normal/good. Please check that you agree
with them. I haven't updated the doctests yet so tests do not pass (and
there's still more documentation to add/fix).
> >
> Was the crystal structure wrong for both the good and cogood methods? I
would not be surprised if the cogood structure was wrong but I would have
thought that the good nodes were right as this is what I are about
more...anyway, thanks for fixing it.
Yes, they were, at least according to Kleshchev and how things were
ordered, but the normal cells were computed correctly (although I had to
flip one of the directions, and I did so to match Kleshchev).
> > I still need to define a similar crystal structure for the level 1
partition tuples. I'm debating whether to use the current setup or to have
it delegate to `e`-regular partitions (and implement a parent for
`e`-restricted partitions). Any preferences?
>
> Of course the way that I had it there was a single parent that had
partitions in level one and partition tuples in higher levels. I can
accept if you ant to move away from this. The good nodes methods etc also
exist in level one but there is of course a much more efficient way to
generate these partitions. As there is a more efficient way to generate
the restricted/regular partitions it makes sense to have a separate parent
for them.
We already have a class for regular partitions, and essentially we have a
class for restricted partitions (which is easy enough to "resurrect").
> On the other hand, in the code that I pushed I had one parent for all
levels and instead made `__iter__` depend on the level. Mathematically, it
makes more sense, I think, to have one parent but the implementation
differences between partitions and 1-tulpes of partitions needs to be
taken into account somewhere. Given my bias I am happy for some one more
objective to make this decision.
I liked the fact that everything was tied to one parent called
`KleshchevPartitions`, but I think it is better to utilize the separate
classes for the essentially distinct behaviors and to take advantage of
their specializations. However, `KleshchevPartitions` would remain the
global entry point, and we can use that as an indicator class by tweaking
the class inheritance. I.e., any class that implements Kleshchev
partitions will be a subclass of `KleshchevPartitions` (this is a common
idiom in various languages (e.g.., Java) by using what are known as
interfaces).
> The second issue, which is probably already addressed in your changes is
whether we should implement both the the "restricted" and "regular"
versions. This is partly a question of taste and conveniences: the
restricted variants are more commonly used in the literature for the
cyclotomic Hecke algebras but the regular versions seem more common in the
crystal world.
We have both given by passing the `direction`. Although we will need to
specify in the doc which direction corresponds to which type (I believe
`up` is restricted and `down` is regular, but I'd need to double-check).
There is also which way we order the partition tuples, which I believe
corresponds to which tensor product convention we use. Do we also want to
deal with that as well?
--
Ticket URL: <http://trac.sagemath.org/ticket/20564#comment:18>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
