Sage: Ticket #15621: Implement regular partition tuples
https://trac.sagemath.org/ticket/15621
<p>
As the title states and needed for <a class="closed ticket" href="https://trac.sagemath.org/ticket/15508" title="#15508: enhancement: Implement Fock space (closed: fixed)">#15508</a>.
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/15621
Trac 1.2Travis ScrimshawThu, 02 Jan 2014 17:26:34 GMTstatus changed
https://trac.sagemath.org/ticket/15621#comment:1
https://trac.sagemath.org/ticket/15621#comment:1
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
</ul>
TicketTravis ScrimshawThu, 02 Jan 2014 17:44:16 GMT
https://trac.sagemath.org/ticket/15621#comment:2
https://trac.sagemath.org/ticket/15621#comment:2
<p>
There is a notable change to the behavior of <code>PartitionTuples</code>, in that it now always returns elements of itself (previously it returned partitions if the element was of level 1).
</p>
TicketAndrew MathasFri, 03 Jan 2014 20:53:46 GMT
https://trac.sagemath.org/ticket/15621#comment:3
https://trac.sagemath.org/ticket/15621#comment:3
<p>
Hi Travis,
</p>
<p>
First, I'd like to say that I am very much against the advertised change that <code>PartitionTuples</code> now always returns a element of this class in level 1 as I think that this is mathematically incorrect (...and it will mean that I have to change some of my own code:). On the other hand, if this is necessary for <a class="closed ticket" href="https://trac.sagemath.org/ticket/15508" title="#15508: enhancement: Implement Fock space (closed: fixed)">#15508</a> or <a class="closed ticket" href="https://trac.sagemath.org/ticket/15525" title="#15525: enhancement: More partition parents and fixes to global options (closed: fixed)">#15525</a> then one way to preserve mathematical correctness might be to use coercions/conversions in level 1? Also, if one does this then in <code>partition_tuple.py</code> shouldn't
</p>
<pre class="wiki">sage: [5,1,1] in PartitionTuples()
True
</pre><p>
return <code>False</code>?
</p>
<p>
Secondly, I am not sure how useful the implemented class <code>RegularPartitionTuples</code> will be. In level 1 this class is useful because the regular partitions index the irreducible representations of the Hecke algebra of type A and (equivalently) a related crystal graph for the irreducible highest weight representation of the quantised affine special linear group. For higher levels I think that the corresponding sets of partition tuples are more complicated than the class you have implemented.
</p>
<p>
The documentation does not seem to say what an element of <code>RegularPartitionTuples</code> is but from the code it looks like these things are just tuples of regular partitions. These partition tuples do not index the crystal bases of the higher level Fock spaces so if this is what this patch implements then it is probably not what you want for <a class="closed ticket" href="https://trac.sagemath.org/ticket/15508" title="#15508: enhancement: Implement Fock space (closed: fixed)">#15508</a>. Except in level 1, the only known descriptions of the partition tuples that arise in the Fock space combinatorics are recursive: more explicitly, these are the partition tuples for which you can construct a path in the crystal graph starting from the empty partition tuple.
</p>
<p>
I have an implementation of the class that is needed for the Fock spaces in <code>u/andrew.mathas/combinat/tableaux_residues</code> where they are called <code>KleshchevPartitions</code> in <code>partition_tuple.py</code>. If I haven't misread what your code does I would be happy to help in trying to merge these two branches -- I don't care what the class is called. My code first implements "good node sequences" for partition tuples. This is the combinatorial data that you need to describe the realisation of the crystal graph that corresponds to the Fock space. The iterator for <code>KleshchevPartitions</code> then, in effect, constructs the crystal graph.
</p>
<p>
I wasn't planning on putting this code into sage any time soon because I thought that no one was interested in it apart from me -- although it is already avalable on git. As a result I haven't properly tested my code, although it is documented and it probably works:) It is also worth mentioning that your Fock space code should give another way of constructing these partition (tuples) using the degrees of the higher level "LLT polynomials" that arise (so it shouldn't need this class). Finally, unfortunately, there are at least four different natural conventions for these objects, all of which are probably used by some one -- in level 1, there are two natural choices related by conjugation of partitions and in higher levels you can conjugate and reverse the order of the partitions in the tuple.
</p>
<p>
Andrew
</p>
TicketTravis ScrimshawSun, 05 Jan 2014 18:40:28 GMTstatus changed
https://trac.sagemath.org/ticket/15621#comment:4
https://trac.sagemath.org/ticket/15621#comment:4
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
Hey Andrew,
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15621#comment:3" title="Comment 3">andrew.mathas</a>:
</p>
<blockquote class="citation">
<p>
First, I'd like to say that I am very much against the advertised change that <code>PartitionTuples</code> now always returns a element of this class in level 1 as I think that this is mathematically incorrect (...and it will mean that I have to change some of my own code:). On the other hand, if this is necessary for <a class="closed ticket" href="https://trac.sagemath.org/ticket/15508" title="#15508: enhancement: Implement Fock space (closed: fixed)">#15508</a> or <a class="closed ticket" href="https://trac.sagemath.org/ticket/15525" title="#15525: enhancement: More partition parents and fixes to global options (closed: fixed)">#15525</a> then one way to preserve mathematical correctness might be to use coercions/conversions in level 1? Also, if one does this then in <code>partition_tuple.py</code> shouldn't
</p>
<pre class="wiki">sage: [5,1,1] in PartitionTuples()
True
</pre><p>
return <code>False</code>?
</p>
</blockquote>
<p>
I was thinking it was necessary for <a class="closed ticket" href="https://trac.sagemath.org/ticket/15508" title="#15508: enhancement: Implement Fock space (closed: fixed)">#15508</a>, but then I realized I was directly using the parent class instead of just going through <code>PartitionTuples</code>. I'll change this back, and put some warnings about this. Although I think we should make sure we can convert from level 1 partition tuples to partitions if the user happens to accidentally have created one.
</p>
<blockquote class="citation">
<p>
Secondly, I am not sure how useful the implemented class <code>RegularPartitionTuples</code> will be.
</p>
<p>
...
</p>
<p>
I wasn't planning on putting this code into sage any time soon because I thought that no one was interested in it apart from me -- although it is already avalable on git. As a result I haven't properly tested my code, although it is documented and it probably works:)
</p>
</blockquote>
<p>
If I understand Fayers correctly, the generalized LLT works for the full tensor product space and the <code>RegularPartitionTuples</code> should index that basis. I had put a TODO message in <a class="closed ticket" href="https://trac.sagemath.org/ticket/15508" title="#15508: enhancement: Implement Fock space (closed: fixed)">#15508</a> about wanting to use a smaller domain. I'm now thinking the best thing to do is just do that now and have both spaces available, but that's something specifically for <a class="closed ticket" href="https://trac.sagemath.org/ticket/15508" title="#15508: enhancement: Implement Fock space (closed: fixed)">#15508</a>.
</p>
<p>
I have <a class="closed ticket" href="https://trac.sagemath.org/ticket/15584" title="#15584: enhancement: Implement the BZ multisegment crystal model (closed: fixed)">#15584</a> which constructs Kleshchev partitions (as well some other crystals, but I can separate out just the Kleshchev partitions if desired), but does so by using the signature rule. I just skimmed over your code, and I think it's different that how you're doing it, but I very easily could be wrong. Nevertheless, we can check them against each other, and if you want, get your code on Kleshchev partitions into Sage as well. I will then use either of them (whichever turns out to be faster/more useful/put into sage) to index the HW basis for <a class="closed ticket" href="https://trac.sagemath.org/ticket/15508" title="#15508: enhancement: Implement Fock space (closed: fixed)">#15508</a>.
</p>
<blockquote class="citation">
<p>
It is also worth mentioning that your Fock space code should give another way of constructing these partition (tuples) using the degrees of the higher level "LLT polynomials" that arise (so it shouldn't need this class).
</p>
</blockquote>
<p>
It would be useful for the <code>__getitem__</code> and <code>_element_constructor_</code> of the HW repr, but I don't think it wouldn't be useful for creating the indexing set for the basis.
</p>
<blockquote class="citation">
<p>
Finally, unfortunately, there are at least four different natural conventions for these objects, all of which are probably used by some one -- in level 1, there are two natural choices related by conjugation of partitions and in higher levels you can conjugate and reverse the order of the partitions in the tuple.
</p>
</blockquote>
<p>
The last one is the oh-so-fun<sup>TM</sup> Kashiwara vs. anti-Kashiwara for tensor products of crystals, but the conjugation should be easy enough to handle. In conclusion there's more to do for <a class="closed ticket" href="https://trac.sagemath.org/ticket/15584" title="#15584: enhancement: Implement the BZ multisegment crystal model (closed: fixed)">#15584</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/15525" title="#15525: enhancement: More partition parents and fixes to global options (closed: fixed)">#15525</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/15508" title="#15508: enhancement: Implement Fock space (closed: fixed)">#15508</a>, and here.
</p>
TicketAndrew MathasSun, 05 Jan 2014 19:36:11 GMT
https://trac.sagemath.org/ticket/15621#comment:5
https://trac.sagemath.org/ticket/15621#comment:5
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15621#comment:4" title="Comment 4">tscrim</a>:
</p>
<blockquote class="citation">
<p>
I was thinking it was necessary for <a class="closed ticket" href="https://trac.sagemath.org/ticket/15508" title="#15508: enhancement: Implement Fock space (closed: fixed)">#15508</a>, but then I realized I was directly using the parent class instead of just going through <code>PartitionTuples</code>. I'll change this back, and put some warnings about this. Although I think we should make sure we can convert from level 1 partition tuples to partitions if the user happens to accidentally have created one.
</p>
</blockquote>
<p>
Perhaps I am being too precious here:) In a discussion on sage-combinat Simon King was certainly very much against the current behaviour...and changing this is certainly not so drastic for my code. The main difference/annoyance is that with this change the level 1 partition tuples would be missing many of the methods of their honest partition counter-parts. Another way out would be to force partition tuples to have level at least 2.
</p>
<blockquote class="citation">
<p>
If I understand Fayers correctly, the generalized LLT works for the full tensor product space and the <code>RegularPartitionTuples</code> should index that basis. I had put a TODO message in <a class="closed ticket" href="https://trac.sagemath.org/ticket/15508" title="#15508: enhancement: Implement Fock space (closed: fixed)">#15508</a> about wanting to use a smaller domain. I'm now thinking the best thing to do is just do that now and have both spaces available, but that's something specifically for <a class="closed ticket" href="https://trac.sagemath.org/ticket/15508" title="#15508: enhancement: Implement Fock space (closed: fixed)">#15508</a>.
</p>
</blockquote>
<p>
OK, I need to look at Fayers properly to see what he does. I've been meaning to do this anyway because my promised comments on <a class="closed ticket" href="https://trac.sagemath.org/ticket/15508" title="#15508: enhancement: Implement Fock space (closed: fixed)">#15508</a> require this.
</p>
<blockquote class="citation">
<p>
I have <a class="closed ticket" href="https://trac.sagemath.org/ticket/15584" title="#15584: enhancement: Implement the BZ multisegment crystal model (closed: fixed)">#15584</a> which constructs Kleshchev partitions (as well some other crystals, but I can separate out just the Kleshchev partitions if desired), but does so by using the signature rule. I just skimmed over your code, and I think it's different that how you're doing it, but I very easily could be wrong. Nevertheless, we can check them against each other, and if you want, get your code on Kleshchev partitions into Sage as well. I will then use either of them (whichever turns out to be faster/more useful/put into sage) to index the HW basis for <a class="closed ticket" href="https://trac.sagemath.org/ticket/15508" title="#15508: enhancement: Implement Fock space (closed: fixed)">#15508</a>.
</p>
</blockquote>
<p>
I suspect that it comes down to the same thing: I am guessing that you are using Kashiwarra's theorem for the tensor product of crystal graphs, in which case our methods should be equivalent.
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
It is also worth mentioning that your Fock space code should give another way of constructing these partition (tuples) using the degrees of the higher level "LLT polynomials" that arise (so it shouldn't need this class).
</p>
</blockquote>
<p>
It would be useful for the <code>__getitem__</code> and <code>_element_constructor_</code> of the HW repr, but I don't think it wouldn't be useful for creating the indexing set for the basis.
</p>
</blockquote>
<p>
I agree it is not useful for constructing the indexing set but I think that it does speed up the calculation of e basis for the highest weight module, primarily because the canonical bases elements which appear in L(\Lambda) are identified by their maximal degree term so you don't ever need to compute the set of Kleshchev multipartitions.
</p>
<p>
Andrew
</p>
TicketTravis ScrimshawSun, 05 Jan 2014 21:35:41 GMT
https://trac.sagemath.org/ticket/15621#comment:6
https://trac.sagemath.org/ticket/15621#comment:6
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15621#comment:5" title="Comment 5">andrew.mathas</a>:
</p>
<blockquote class="citation">
<p>
Perhaps I am being too precious here:) In a discussion on sage-combinat Simon King was certainly very much against the current behaviour...and changing this is certainly not so drastic for my code. The main difference/annoyance is that with this change the level 1 partition tuples would be missing many of the methods of their honest partition counter-parts. Another way out would be to force partition tuples to have level at least 2.
</p>
</blockquote>
<p>
Just to be clear, I'm not changing the output of things like <code>PartitionTuples(level=1)</code>, this will still return <code>Partitions</code>, but instead the <code>__iter__()</code> over elements of <code>PartitionTuples()</code> and the corresponding <code>_element_constructor_()</code>, which where not returning elements of the corresponding parent object. So we get things like
</p>
<pre class="wiki">sage: P = PartitionTuples()
sage: pt = P([[3,1,1]]); pt
([3, 1, 1])
sage: pt.parent() is P
True
</pre><p>
where previously the element constructed was a <code>Partition</code> object whose parent was <code>Partitions()</code>. As I recall, Simon was against the parent object returned what not a subclass of <code>PartitionTuple</code> (but I'm okay with it). I'd be surprised if you were using something specific to <code>Partition</code> when iterating or constructing elements from a parent over varying levels (at least without a check on the level).
</p>
TicketFor batch modificationsThu, 30 Jan 2014 21:20:52 GMTmilestone changed
https://trac.sagemath.org/ticket/15621#comment:7
https://trac.sagemath.org/ticket/15621#comment:7
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.1</em> to <em>sage-6.2</em>
</li>
</ul>
TicketFor batch modificationsTue, 06 May 2014 15:20:58 GMTmilestone changed
https://trac.sagemath.org/ticket/15621#comment:8
https://trac.sagemath.org/ticket/15621#comment:8
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.2</em> to <em>sage-6.3</em>
</li>
</ul>
TicketFor batch modificationsSun, 10 Aug 2014 16:51:03 GMTmilestone changed
https://trac.sagemath.org/ticket/15621#comment:9
https://trac.sagemath.org/ticket/15621#comment:9
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.3</em> to <em>sage-6.4</em>
</li>
</ul>
TicketgitSat, 05 Sep 2015 00:37:36 GMTcommit changed
https://trac.sagemath.org/ticket/15621#comment:10
https://trac.sagemath.org/ticket/15621#comment:10
<ul>
<li><strong>commit</strong>
changed from <em>12f1d6b082f64d8d3ed56d8b04877e99aa634baa</em> to <em>2ec0a28aa828a2496171fff48989a7d229a7f787</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=2ec0a28aa828a2496171fff48989a7d229a7f787"><span class="icon"></span>2ec0a28</a></td><td><code>Merge branch 'public/combinat/regular_partition_tuples' of git://trac.sagemath.org/sage into public/combinat/regular_partition_tuples</code>
</td></tr></table>
TicketgitThu, 29 Oct 2015 16:34:46 GMTcommit changed
https://trac.sagemath.org/ticket/15621#comment:11
https://trac.sagemath.org/ticket/15621#comment:11
<ul>
<li><strong>commit</strong>
changed from <em>2ec0a28aa828a2496171fff48989a7d229a7f787</em> to <em>c6a4f44b22b1c8a90215da7bb9f7f29302bde49a</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=2fda6198c97701be26a1b25840b7c79de1284766"><span class="icon"></span>2fda619</a></td><td><code>Merge branch 'public/combinat/regular_partition_tuples' of trac.sagemath.org:sage into public/combinat/regular_partition_tuples</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=c6a4f44b22b1c8a90215da7bb9f7f29302bde49a"><span class="icon"></span>c6a4f44</a></td><td><code>Some fixes and tweaks from rebasing.</code>
</td></tr></table>
TicketTravis ScrimshawThu, 29 Oct 2015 16:43:52 GMT
https://trac.sagemath.org/ticket/15621#comment:12
https://trac.sagemath.org/ticket/15621#comment:12
<p>
Hey Andrew,
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15621#comment:4" title="Comment 4">tscrim</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15621#comment:3" title="Comment 3">andrew.mathas</a>:
</p>
<blockquote class="citation">
<p>
First, I'd like to say that I am very much against the advertised change that <code>PartitionTuples</code> now always returns a element of this class in level 1 as I think that this is mathematically incorrect (...and it will mean that I have to change some of my own code:). On the other hand, if this is necessary for <a class="closed ticket" href="https://trac.sagemath.org/ticket/15508" title="#15508: enhancement: Implement Fock space (closed: fixed)">#15508</a> or <a class="closed ticket" href="https://trac.sagemath.org/ticket/15525" title="#15525: enhancement: More partition parents and fixes to global options (closed: fixed)">#15525</a> then one way to preserve mathematical correctness might be to use coercions/conversions in level 1? Also, if one does this then in <code>partition_tuple.py</code> shouldn't
</p>
<pre class="wiki">sage: [5,1,1] in PartitionTuples()
True
</pre><p>
return <code>False</code>?
</p>
</blockquote>
<p>
I was thinking it was necessary for <a class="closed ticket" href="https://trac.sagemath.org/ticket/15508" title="#15508: enhancement: Implement Fock space (closed: fixed)">#15508</a>, but then I realized I was directly using the parent class instead of just going through <code>PartitionTuples</code>. I'll change this back, and put some warnings about this. Although I think we should make sure we can convert from level 1 partition tuples to partitions if the user happens to accidentally have created one.
</p>
</blockquote>
<p>
I noticed an inconsistency with this. In particular, we currently have:-
</p>
<pre class="wiki">sage: la = Partition([3,3,1])
sage: PT = PartitionTuples()
sage: la in PT
</pre><p>
So either we should have my change where the quoted example should be <code>True</code>, or we change it so that the example I gave returns <code>False</code>. Which would you prefer?
</p>
TicketTravis ScrimshawThu, 29 Oct 2015 17:32:22 GMTstatus, milestone changed
https://trac.sagemath.org/ticket/15621#comment:13
https://trac.sagemath.org/ticket/15621#comment:13
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_info</em>
</li>
<li><strong>milestone</strong>
changed from <em>sage-6.4</em> to <em>sage-6.10</em>
</li>
</ul>
TicketgitThu, 29 Oct 2015 17:34:26 GMTcommit changed
https://trac.sagemath.org/ticket/15621#comment:14
https://trac.sagemath.org/ticket/15621#comment:14
<ul>
<li><strong>commit</strong>
changed from <em>c6a4f44b22b1c8a90215da7bb9f7f29302bde49a</em> to <em>340df1bea4879a7e695d2133edb94993ffa2137a</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=340df1bea4879a7e695d2133edb94993ffa2137a"><span class="icon"></span>340df1b</a></td><td><code>Adding another doctest for containment.</code>
</td></tr></table>
TicketgitFri, 30 Oct 2015 14:59:47 GMTcommit changed
https://trac.sagemath.org/ticket/15621#comment:15
https://trac.sagemath.org/ticket/15621#comment:15
<ul>
<li><strong>commit</strong>
changed from <em>340df1bea4879a7e695d2133edb94993ffa2137a</em> to <em>809cc130b52b00c21f14e57ff2b8296f60dafaed</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=809cc130b52b00c21f14e57ff2b8296f60dafaed"><span class="icon"></span>809cc13</a></td><td><code>Fixing input of TableauxTuple to handle level 1 partition tuple input.</code>
</td></tr></table>
TicketAndrew MathasTue, 03 Nov 2015 13:00:42 GMT
https://trac.sagemath.org/ticket/15621#comment:16
https://trac.sagemath.org/ticket/15621#comment:16
<blockquote class="citation">
<p>
I noticed an inconsistency with this. In particular, we currently have:-
</p>
<pre class="wiki">sage: la = Partition([3,3,1])
sage: PT = PartitionTuples()
sage: la in PT
</pre><p>
So either we should have my change where the quoted example should be <code>True</code>, or we change it so that the example I gave returns <code>False</code>. Which would you prefer?
</p>
</blockquote>
<p>
Yes, this is certainly a bug. I would prefer the following:
</p>
<pre class="wiki">sage: Partition([3,3,1]) in PartitionTuples()
True
sage: [3,3,1] in PartitionTuples()
True # ** currently returns False
</pre><p>
I am not sure if this is compatible with what you are proposing.
</p>
<p>
Andrew
</p>
TicketTravis ScrimshawTue, 03 Nov 2015 19:32:15 GMTstatus changed
https://trac.sagemath.org/ticket/15621#comment:17
https://trac.sagemath.org/ticket/15621#comment:17
<ul>
<li><strong>status</strong>
changed from <em>needs_info</em> to <em>needs_review</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15621#comment:16" title="Comment 16">andrew.mathas</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
I noticed an inconsistency with this. In particular, we currently have:-
</p>
<pre class="wiki">sage: la = Partition([3,3,1])
sage: PT = PartitionTuples()
sage: la in PT
</pre><p>
So either we should have my change where the quoted example should be <code>True</code>, or we change it so that the example I gave returns <code>False</code>. Which would you prefer?
</p>
</blockquote>
<p>
Yes, this is certainly a bug. I would prefer the following:
</p>
<pre class="wiki">sage: Partition([3,3,1]) in PartitionTuples()
True
sage: [3,3,1] in PartitionTuples()
True # ** currently returns False
</pre><p>
I am not sure if this is compatible with what you are proposing.
</p>
</blockquote>
<p>
Yes it is as <code>__contains__</code> does not have to mean the checked object is an honest element of the parent. However it's just the output when passed through <code>PartitionTuples()</code> will be a tuple of size 1:
</p>
<pre class="wiki">sage: PT = PartitionTuples()
sage: [3,3,1] in PT
True
sage: PT([3,3,1])
([3, 3, 1])
</pre><p>
I was worried about which way you wanted given your statement on <a class="ticket" href="https://trac.sagemath.org/ticket/15621#comment:3" title="Comment 3">comment:3</a>.
</p>
<p>
However I will add a conversion from level 1 partition tuples to the corresponding set of partitions.
</p>
TicketgitTue, 03 Nov 2015 20:02:04 GMTcommit changed
https://trac.sagemath.org/ticket/15621#comment:18
https://trac.sagemath.org/ticket/15621#comment:18
<ul>
<li><strong>commit</strong>
changed from <em>809cc130b52b00c21f14e57ff2b8296f60dafaed</em> to <em>f113a0fa7344c1f1c86d74c216c132c75c46e7a1</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=f113a0fa7344c1f1c86d74c216c132c75c46e7a1"><span class="icon"></span>f113a0f</a></td><td><code>Some attempts at cleaning up the containment checks and converion from tuples.</code>
</td></tr></table>
TicketTravis ScrimshawTue, 03 Nov 2015 20:12:28 GMT
https://trac.sagemath.org/ticket/15621#comment:19
https://trac.sagemath.org/ticket/15621#comment:19
<p>
I also noticed some places where containment checking led to errors being raised and took care of where I saw those on the last commit.
</p>
<p>
I also elected to not have a level 1 partition tuple register as being contained in <code>Partitions</code> as getting equivalent forms of partition tuples, such as <code>[[4,3,3,1]]</code> and <code>([4,3,3,1])</code> (as a tuple/list of a list) seems fraught with issues and lots of checks that would likely cause slowdowns in the containment checks. If you are checking for containment, you probably are going to convert afterwards, so I would actually say the more pythonic way is to try the conversion and then handle the raised error if it cannot be done.
</p>
<p>
Perhaps more succinctly, I don't think there is necessarily a perfect solution with the current implementation, but this is the best for our current applications.
</p>
TicketgitTue, 10 May 2016 20:21:54 GMTcommit changed
https://trac.sagemath.org/ticket/15621#comment:20
https://trac.sagemath.org/ticket/15621#comment:20
<ul>
<li><strong>commit</strong>
changed from <em>f113a0fa7344c1f1c86d74c216c132c75c46e7a1</em> to <em>6ac89794e490e0632816701bd736babfb3045d12</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=d4e57ba311a3530975bfe9f7406d9136b97896ce"><span class="icon"></span>d4e57ba</a></td><td><code>Merge branch 'public/combinat/regular_partition_tuples' of git://trac.sagemath.org/sage into partup</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=637aee73b6ece9becf389ada36364382c35e3d8a"><span class="icon"></span>637aee7</a></td><td><code>technical improvements to partition.py (j/w/w Travis)</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=6ac89794e490e0632816701bd736babfb3045d12"><span class="icon"></span>6ac8979</a></td><td><code>various</code>
</td></tr></table>
TicketDarij GrinbergTue, 10 May 2016 20:24:21 GMT
https://trac.sagemath.org/ticket/15621#comment:21
https://trac.sagemath.org/ticket/15621#comment:21
<p>
The code LGTM. Another issue that caught my mind in the process, but isn't exactly related, is <a class="closed ticket" href="https://trac.sagemath.org/ticket/20584" title="#20584: defect: Regular partitions: 1-regular partitions are mishandled on occasion (closed: fixed)">#20584</a>.
</p>
TicketDarij GrinbergTue, 10 May 2016 20:25:01 GMTstatus, milestone changed; reviewer set; dependencies deleted
https://trac.sagemath.org/ticket/15621#comment:22
https://trac.sagemath.org/ticket/15621#comment:22
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
<li><strong>reviewer</strong>
set to <em>Darij Grinberg</em>
</li>
<li><strong>dependencies</strong>
<em>#15525</em> deleted
</li>
<li><strong>milestone</strong>
changed from <em>sage-6.10</em> to <em>sage-7.3</em>
</li>
</ul>
TicketVolker BraunTue, 17 May 2016 07:16:50 GMTstatus, branch changed; resolution set
https://trac.sagemath.org/ticket/15621#comment:23
https://trac.sagemath.org/ticket/15621#comment:23
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
<li><strong>branch</strong>
changed from <em>public/combinat/regular_partition_tuples</em> to <em>6ac89794e490e0632816701bd736babfb3045d12</em>
</li>
</ul>
Ticket