#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 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.
> 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. 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.
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.
--
Ticket URL: <http://trac.sagemath.org/ticket/20564#comment:17>
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.
