Sage: Ticket #20469: Implement Ariki-Koike algebras
https://trac.sagemath.org/ticket/20469
<p>
An Ariki-Koike algebra is the Hecke algebra of the complex reflection group G(r,1,n).
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/20469
Trac 1.1.6stumpc5Tue, 19 Apr 2016 19:10:54 GMTcc changed
https://trac.sagemath.org/ticket/20469#comment:1
https://trac.sagemath.org/ticket/20469#comment:1
<ul>
<li><strong>cc</strong>
<em>stumpc5</em> added
</li>
</ul>
TickettscrimFri, 06 May 2016 03:45:01 GMTcc changed; commit, branch set
https://trac.sagemath.org/ticket/20469#comment:2
https://trac.sagemath.org/ticket/20469#comment:2
<ul>
<li><strong>cc</strong>
<em>andrew.mathas</em> added
</li>
<li><strong>commit</strong>
set to <em>f644c20f0c297faf9dc98e4bab70c5985131d390</em>
</li>
<li><strong>branch</strong>
set to <em>public/algebras/ariki_koike_algebras-20469</em>
</li>
</ul>
<p>
Here is the first version. I still have to convert from Ariki-Koike's version to the Hu-Mathas definition, but this version seems to work (in particular, it passed a few of my associativity tests and the relations I tested). There is also more documentation that needs to be added. I'm also not completely satisfied with the default base ring. However, I wanted to get feedback.
</p>
<p>
Note that the multiplication is highly recursive. In particular, once there is an l<sub>i</sub><sup>r</sup> occurring, it can easily run into Python's recursion limit. It might be possible to work this out with handling the manipulations within the code here or doing parts of the multiplication in bigger chunks. However, this would take a lot of work I think to improve and the code works.
</p>
<p>
I am also planning on implementing the isomorphism with type A<sub>n</sub>/B<sub>n</sub> Hecke algebras shortly too.
</p>
<hr />
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=f644c20f0c297faf9dc98e4bab70c5985131d390"><span class="icon"></span>f644c20</a></td><td><code>Initial implementation of Ariki-Koike alegbras.</code>
</td></tr></table>
Ticketandrew.mathasFri, 06 May 2016 04:44:18 GMT
https://trac.sagemath.org/ticket/20469#comment:3
https://trac.sagemath.org/ticket/20469#comment:3
<p>
Thanks Travis. This looks interesting. I will have a play with it and see if I can improve the multiplication with the tricks that I know about these algebras -- I am not promising that this will be possible, only to look!
</p>
<p>
Some initial comments:
</p>
<ul><li>It would be better to use <code>L1</code>,<code>...</code>,<code>Ln</code> for the Jucys-Murphy elements as this is what is commonly used in the literature and it's also consistent with using <code>T1</code>,<code>T2</code>,<code>...</code> for the Hecke generators. Using <code>l1</code>,<code>...</code>,<code>ln</code> looks strange to me.
</li><li>I am not sure that it is worth the effort to define the Hu-Mathas as the algebras that we defined are different to these when <code>q=1</code> and, more importantly, the conversion between the two is easy in principle but messy in practice.
</li><li>The default base ring should be the smallest ring that contains <code>q</code>, <code>u0</code>,...,<code>ur</code>.
</li><li>At some stage I will polish the code that I have which implements the Specht modules for these algebras. Given this it would probably be a good idea to put this code in its own subdirectory so that the module code. Similarly, my graded Specht module could go in here to.
</li></ul>
TicketgitFri, 06 May 2016 16:41:13 GMTcommit changed
https://trac.sagemath.org/ticket/20469#comment:4
https://trac.sagemath.org/ticket/20469#comment:4
<ul>
<li><strong>commit</strong>
changed from <em>f644c20f0c297faf9dc98e4bab70c5985131d390</em> to <em>21a49dfec02d086a07e888ecef48529dffa302b6</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=79cc75797008bca028a95ffecb24b4d37a05997b"><span class="icon"></span>79cc757</a></td><td><code>Changing l -> L.</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=c4b3588a2a37ff1da086aa9189164a158b6b32ec"><span class="icon"></span>c4b3588</a></td><td><code>Moving Ariki-Koike algebras to new subfolder for Hecke algebras.</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=fd0097fc53d83f8ccb3f067ae38402bee74660bb"><span class="icon"></span>fd0097f</a></td><td><code>Adding more documentation and examples. Doing some fixes.</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=21a49dfec02d086a07e888ecef48529dffa302b6"><span class="icon"></span>21a49df</a></td><td><code>Fixing an error with multiplication of the T_i generators.</code>
</td></tr></table>
TickettscrimFri, 06 May 2016 16:56:27 GMT
https://trac.sagemath.org/ticket/20469#comment:5
https://trac.sagemath.org/ticket/20469#comment:5
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/20469#comment:3" title="Comment 3">andrew.mathas</a>:
</p>
<blockquote class="citation">
<p>
Thanks Travis. This looks interesting. I will have a play with it and see if I can improve the multiplication with the tricks that I know about these algebras -- I am not promising that this will be possible, only to look!
</p>
</blockquote>
<p>
Great, thanks. It is currently so recursive that it fails for <code>L2 * L1 * L2</code> in <code>H(2,2)</code> (although <code>L1 * (L2)^2</code> works).
</p>
<blockquote class="citation">
<ul><li>It would be better to use <code>L1</code>,<code>...</code>,<code>Ln</code> for the Jucys-Murphy elements as this is what is commonly used in the literature and it's also consistent with using <code>T1</code>,<code>T2</code>,<code>...</code> for the Hecke generators. Using <code>l1</code>,<code>...</code>,<code>ln</code> looks strange to me.
</li></ul></blockquote>
<p>
Done.
</p>
<blockquote class="citation">
<ul><li>I am not sure that it is worth the effort to define the Hu-Mathas as the algebras that we defined are different to these when <code>q=1</code> and, more importantly, the conversion between the two is easy in principle but messy in practice.
</li></ul></blockquote>
<p>
This also leads to a question of what do we want to call the Hu-Mathas variant? In the future, we can also add another basis to this for <code>q \neq 1</code>. We also should probably add the basis indexed by the colored permutations (i.e., monomials in <code>T_0, ..., T_{n-1}</code>).
</p>
<blockquote class="citation">
<ul><li>The default base ring should be the smallest ring that contains <code>q</code>, <code>u0</code>,...,<code>ur</code>.
</li></ul></blockquote>
<p>
With <code>q</code> invertible, that is what it currently does (just in a slightly funky way that groups the <code>u</code>'s together then the <code>q</code>'s).
</p>
<blockquote class="citation">
<ul><li>At some stage I will polish the code that I have which implements the Specht modules for these algebras. Given this it would probably be a good idea to put this code in its own subdirectory so that the module code. Similarly, my graded Specht module could go in here to.
</li></ul></blockquote>
<p>
I have moved this into a <code>hecke_algebras</code> folder to start. We can move the rest of the Hecke algebras (e.g., Iwahori and Yokonuma) to this folder on a followup ticket.
</p>
<p>
While adding the documentation, I also found some errors with the multiplication that I have fixed.
</p>
TicketgitSat, 07 May 2016 02:15:22 GMTcommit changed
https://trac.sagemath.org/ticket/20469#comment:6
https://trac.sagemath.org/ticket/20469#comment:6
<ul>
<li><strong>commit</strong>
changed from <em>21a49dfec02d086a07e888ecef48529dffa302b6</em> to <em>76e643fe3b04ff5f78d882311688e92b2aafddd6</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=76e643fe3b04ff5f78d882311688e92b2aafddd6"><span class="icon"></span>76e643f</a></td><td><code>Fixing multiplication the other way.</code>
</td></tr></table>
TicketgitTue, 12 Jul 2016 22:47:45 GMTcommit changed
https://trac.sagemath.org/ticket/20469#comment:7
https://trac.sagemath.org/ticket/20469#comment:7
<ul>
<li><strong>commit</strong>
changed from <em>76e643fe3b04ff5f78d882311688e92b2aafddd6</em> to <em>e9b6a594ae1e089b51b37081f35743402447a960</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="https://git.sagemath.org/sage.git/commit/?id=bcd1ef47513863a6c065cb101373a00dcd3f2308"><span class="icon"></span>bcd1ef4</a></td><td><code>Initial implementation of Ariki-Koike alegbras.</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=93b57ff5687ee39b75014ca323cd5a17a3f3cca5"><span class="icon"></span>93b57ff</a></td><td><code>Changing l -> L.</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=a98d138d39e89b3d521d2b8d1161c04ce4412361"><span class="icon"></span>a98d138</a></td><td><code>Moving Ariki-Koike algebras to new subfolder for Hecke algebras.</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=5e739babc03cf6694ffa574118b59e007f0fd8b6"><span class="icon"></span>5e739ba</a></td><td><code>Adding more documentation and examples. Doing some fixes.</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=f5f5795774a550477928886e346e06e5be723e2c"><span class="icon"></span>f5f5795</a></td><td><code>Fixing an error with multiplication of the T_i generators.</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=13fdc45a7344c34370b3fdfb360d1d68fdcb627b"><span class="icon"></span>13fdc45</a></td><td><code>Fixing multiplication the other way.</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=dae0031049f5bd6e51576a57308c57fd71a3fe92"><span class="icon"></span>dae0031</a></td><td><code>Initial review</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=f9cd18563894ad05eec3019dfb92d5dffc031e11"><span class="icon"></span>f9cd185</a></td><td><code>Merge branch 'develop' into t/20469/public/algebras/ariki_koike_algebras-20469</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=7282c3777ac147f6bfed6f95d3305a8b8e150635"><span class="icon"></span>7282c37</a></td><td><code>Rewriting product code to avoid recursion</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=e9b6a594ae1e089b51b37081f35743402447a960"><span class="icon"></span>e9b6a59</a></td><td><code>Merging with remote</code>
</td></tr></table>
Ticketandrew.mathasTue, 12 Jul 2016 23:12:34 GMT
https://trac.sagemath.org/ticket/20469#comment:8
https://trac.sagemath.org/ticket/20469#comment:8
<p>
Hi Travis,
</p>
<p>
I have been through your code and fixed the recursion issue. It was actually an infinite recursion loop. The problem was that as the terms in the products <code>....T_i L_k...</code> were being put into standard form "letter-by-letter" (so changing the previous expression to <code>\sum ... L_m T_j...</code>) you sometimes ended up going around in circles by pushing a <code>T_i</code> past an <code>L_k</code> that then created a large power of some <code>L_m</code> that, when reduced, got you back to the previous situation. I have rewritten the <code>product_on_basis</code> code to avoid this, so I'm afraid that I've replaced this section of your code. The product code is now less recursive with terms largely being rewritten into standard form "in place".
</p>
<p>
On top of this I proved a formula for the expansion of <code>L_k^m</code> that, embarrassingly, I later found in one of my papers. This was my first guess for improving the multiplication issues but once I'd made this change I discovered the recursion loop. The other main change is that I rescaled <code>L_k</code> to <code>q**{1-k}*L_k</code>, in [AK] notation, because this renormalisation is what is normally used in the literature as it works better with the combinatorics.
</p>
<p>
I have made a start at adding the documentation. As a result of the rescaling of the <code>L_k</code>'s quite a lot of doc-tests are currently failing, being off by the corresponding power of <code>q</code>. I am happy to fix these. I left them in only so that you can compare if you wish. I am also happy to fill out the documentation as I know this area quite well.
</p>
<p>
Other issues that we could think about are:
</p>
<ul><li>whether to allow the two parameter version: <code>(T_i-q1)(T_i+q2)=0</code>. Probably quite painful as all of the product formulas will change
</li><li>whether to implement the degenerate algebras. This might be easy as it could be done as a derived class with slightly different <code>_product_LTwTv</code>, <code>_product_Tw_L</code>, and <code>_Li_power</code> methods
</li><li>I think having a slightly shorter <code>_repr_</code> string would be a good idea: <code>Ariki-Koike algebra of rank 5 with parameters q,u0,u2,u3</code> is enough I think
</li><li>implementing other bases? This is probably best left for another ticket...especially as I think that the realisations code currently requires that the same indexing sets be used(?)
</li></ul><p>
Any way, I think that the code now works. Please have a look and let me know what you think. Happy to be a reviewer or coauthor on the ticket as you think best.
</p>
<p>
Andrew
</p>
Ticketandrew.mathasTue, 12 Jul 2016 23:17:22 GMT
https://trac.sagemath.org/ticket/20469#comment:9
https://trac.sagemath.org/ticket/20469#comment:9
<p>
ps. With the degenerate algebras, the other option would be to use the Hu-Mathas presentation for the "main" algebra (this combines the Ariki-Koike algebras with <code>q\ne1</code> and the degenerate AK algebras (when <code>q=1</code>) and then implement the <code>q=1</code> version of the Ariki-Koike algebras as the "extra" case. I am biased, but personally I think that makes more sense because the Hu-M. presentation fits with the KLR categorifiction of integrable highest weight modules perfectly whereas the Ariki-Koike presentation does not.
</p>
TickettscrimWed, 13 Jul 2016 02:19:05 GMTcc, milestone, author changed; reviewer set
https://trac.sagemath.org/ticket/20469#comment:10
https://trac.sagemath.org/ticket/20469#comment:10
<ul>
<li><strong>cc</strong>
<em>tscrim</em> added
</li>
<li><strong>reviewer</strong>
set to <em>Andrew Mathas, Travis Scrimshaw</em>
</li>
<li><strong>milestone</strong>
changed from <em>sage-7.2</em> to <em>sage-7.3</em>
</li>
<li><strong>author</strong>
changed from <em>Travis Scrimshaw</em> to <em>Travis Scrimshaw, Andrew Mathas</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/20469#comment:8" title="Comment 8">andrew.mathas</a>:
</p>
<blockquote class="citation">
<p>
I have been through your code and fixed the recursion issue. It was actually an infinite recursion loop. The problem was that as the terms in the products <code>....T_i L_k...</code> were being put into standard form "letter-by-letter" (so changing the previous expression to <code>\sum ... L_m T_j...</code>) you sometimes ended up going around in circles by pushing a <code>T_i</code> past an <code>L_k</code> that then created a large power of some <code>L_m</code> that, when reduced, got you back to the previous situation. I have rewritten the <code>product_on_basis</code> code to avoid this, so I'm afraid that I've replaced this section of your code. The product code is now less recursive with terms largely being rewritten into standard form "in place".
</p>
</blockquote>
<p>
Thank you very much for looking through this code and fixing the problem(s). Sorry it ended up being a bit of a mess. I'm very happy you were able to improve it.
</p>
<blockquote class="citation">
<p>
On top of this I proved a formula for the expansion of <code>L_k^m</code> that, embarrassingly, I later found in one of my papers. This was my first guess for improving the multiplication issues but once I'd made this change I discovered the recursion loop. The other main change is that I rescaled <code>L_k</code> to <code>q**{1-k}*L_k</code>, in [AK] notation, because this renormalisation is what is normally used in the literature as it works better with the combinatorics.
</p>
</blockquote>
<p>
I probably could have looked harder in the literature. I'm okay with the renormalization (especially since I have more of an interest in the combinatorics too). I just kept the [AK] normalization since I was using that as my reference and didn't trust myself to correctly handle the renormalization.
</p>
<blockquote class="citation">
<p>
I have made a start at adding the documentation. As a result of the rescaling of the <code>L_k</code>'s quite a lot of doc-tests are currently failing, being off by the corresponding power of <code>q</code>. I am happy to fix these. I left them in only so that you can compare if you wish. I am also happy to fill out the documentation as I know this area quite well.
</p>
</blockquote>
<p>
I would appreciate all of your expertise in writing the documentation. I can go over it and do any necessary formatting. I can also fix the doctests afterwards.
</p>
<blockquote class="citation">
<p>
Other issues that we could think about are:
</p>
<ul><li>whether to allow the two parameter version: <code>(T_i-q1)(T_i+q2)=0</code>. Probably quite painful as all of the product formulas will change
</li></ul></blockquote>
<p>
I think it is good to try and be as general as possible when it is not much work. I agree, I think it would be very annoying to switch because we would have to redo all of the product formulas (at least, I would have to put some thought on how to do this to make everything consistent). So, I think this is plenty good for now.
</p>
<blockquote class="citation">
<ul><li>whether to implement the degenerate algebras. This might be easy as it could be done as a derived class with slightly different <code>_product_LTwTv</code>, <code>_product_Tw_L</code>, and <code>_Li_power</code> methods
</li></ul></blockquote>
<blockquote class="citation">
<ul><li>I think having a slightly shorter <code>_repr_</code> string would be a good idea: <code>Ariki-Koike algebra of rank 5 with parameters q,u0,u2,u3</code> is enough I think
</li></ul></blockquote>
<p>
I think we should give the base ring to better differentiate the instances. Plus this is consistent with what we do elsewhere in Sage. One slight issue is the default ring is a polynomial ring over a polynomial ring, and it is this that makes the repr very long. I decided to do this for the default ring so the q's would be grouped together.
</p>
<blockquote class="citation">
<ul><li>implementing other bases? This is probably best left for another ticket...especially as I think that the realisations code currently requires that the same indexing sets be used(?)
</li></ul></blockquote>
<p>
I agree; this should be another ticket unless you have code ready. The realizations code itself does not require the same indexing set, but you have to do a bit more with the morphisms. For an example, see the descent algebra (<code>combinat/descent_algebra.py</code>).
</p>
<blockquote class="citation">
<p>
Any way, I think that the code now works. Please have a look and let me know what you think. Happy to be a reviewer or coauthor on the ticket as you think best.
</p>
</blockquote>
<p>
I will play around with in shortly. We will both be both coauthors and reviewers (yet again :P).
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/20469#comment:9" title="Comment 9">andrew.mathas</a>:
</p>
<blockquote class="citation">
<p>
ps. With the degenerate algebras, the other option would be to use the Hu-Mathas presentation for the "main" algebra (this combines the Ariki-Koike algebras with <code>q\ne1</code> and the degenerate AK algebras (when <code>q=1</code>) and then implement the <code>q=1</code> version of the Ariki-Koike algebras as the "extra" case. I am biased, but personally I think that makes more sense because the Hu-M. presentation fits with the KLR categorifiction of integrable highest weight modules perfectly whereas the Ariki-Koike presentation does not.
</p>
</blockquote>
<p>
I'm +1 for getting things closer to the KLR algebra (something that I hope to eventually get into Sage at some point). Otherwise I don't have an opinion on which presentation we use. How much would have to be changed in order to move to the Hu-Mathas presentation?
</p>
Ticketandrew.mathasWed, 13 Jul 2016 14:50:36 GMT
https://trac.sagemath.org/ticket/20469#comment:11
https://trac.sagemath.org/ticket/20469#comment:11
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/20469#comment:10" title="Comment 10">tscrim</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/20469#comment:8" title="Comment 8">andrew.mathas</a>:
</p>
</blockquote>
<blockquote class="citation">
<p>
I'm +1 for getting things closer to the KLR algebra (something that I hope to eventually get into Sage at some point). Otherwise I don't have an opinion on which presentation we use. How much would have to be changed in order to move to the Hu-Mathas presentation?
</p>
</blockquote>
<p>
With all of these things it is mainly a matter of implementing appropriate analogues of the three methods <code>_product_LTwTv</code>, <code>_product_Tw_L</code>, and <code>_Li_power</code> that underpin the multiplication. Replacing <code>q</code> with a two variable version may be the hardest option as we'd have to think what the appropriate normalisation of the Jucys-Murphy elements is. This said, I would prefer to have the more symmetric relations <code>(T_i-q)(T_i+q^{-1})=0</code>, so I will have a think about this.
</p>
<p>
Regarding KLR algebras, implementing the "affine" KLR algebras is reasonably straightforward. I know now of a way to do the cyclotomic quotients in a few cases and I will implement them at some point, although the isomorphism to the ungraded algebras is much harder to do.
</p>
TickettscrimFri, 15 Jul 2016 03:54:30 GMT
https://trac.sagemath.org/ticket/20469#comment:12
https://trac.sagemath.org/ticket/20469#comment:12
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/20469#comment:11" title="Comment 11">andrew.mathas</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/20469#comment:10" title="Comment 10">tscrim</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/20469#comment:8" title="Comment 8">andrew.mathas</a>:
</p>
</blockquote>
<blockquote class="citation">
<p>
I'm +1 for getting things closer to the KLR algebra (something that I hope to eventually get into Sage at some point). Otherwise I don't have an opinion on which presentation we use. How much would have to be changed in order to move to the Hu-Mathas presentation?
</p>
</blockquote>
<p>
With all of these things it is mainly a matter of implementing appropriate analogues of the three methods <code>_product_LTwTv</code>, <code>_product_Tw_L</code>, and <code>_Li_power</code> that underpin the multiplication. Replacing <code>q</code> with a two variable version may be the hardest option as we'd have to think what the appropriate normalisation of the Jucys-Murphy elements is. This said, I would prefer to have the more symmetric relations <code>(T_i-q)(T_i+q^{-1})=0</code>, so I will have a think about this.
</p>
</blockquote>
<p>
I believe I've said this above, but to be pedantic, I have no preference as to what quadratic relation is. How much could be obtained by looking at the affine Hecke algebra and passing to the quotient?
</p>
<blockquote class="citation">
<p>
Regarding KLR algebras, implementing the "affine" KLR algebras is reasonably straightforward. I know now of a way to do the cyclotomic quotients in a few cases and I will implement them at some point, although the isomorphism to the ungraded algebras is much harder to do.
</p>
</blockquote>
<p>
Please cc me on that ticket when you create it. I would be happy to review it.
</p>
TicketgitWed, 09 Aug 2017 05:42:36 GMTcommit changed
https://trac.sagemath.org/ticket/20469#comment:13
https://trac.sagemath.org/ticket/20469#comment:13
<ul>
<li><strong>commit</strong>
changed from <em>e9b6a594ae1e089b51b37081f35743402447a960</em> to <em>f39c1399357d574109fb152cf456d8690fadde1b</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="https://git.sagemath.org/sage.git/commit/?id=abe87649263a7e66b73b6a06905c6222d1c9a8da"><span class="icon"></span>abe8764</a></td><td><code>Merge branch 'public/algebras/ariki_koike_algebras-20469' of trac.sagemath.org:sage into public/algebras/ariki_koike_algebras-20469</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=0345a42e7b30dd457087183fceb055bb9675bfae"><span class="icon"></span>0345a42</a></td><td><code>Merge branch 'develop' into public/algebras/ariki_koike_algebras-20469</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=0ec4023bda1fa3f055f92a88ab4f4d2b199475bd"><span class="icon"></span>0ec4023</a></td><td><code>Merge branch 'develop' into public/algebras/ariki_koike_algebras-20469</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=f39c1399357d574109fb152cf456d8690fadde1b"><span class="icon"></span>f39c139</a></td><td><code>Merge branch 'develop' into public/algebras/ariki_koike_algebras-20469</code>
</td></tr></table>
TickettscrimWed, 09 Aug 2017 14:17:35 GMTmilestone changed
https://trac.sagemath.org/ticket/20469#comment:14
https://trac.sagemath.org/ticket/20469#comment:14
<ul>
<li><strong>milestone</strong>
changed from <em>sage-7.3</em> to <em>sage-8.1</em>
</li>
</ul>
TicketgitWed, 09 Aug 2017 14:18:14 GMTcommit changed
https://trac.sagemath.org/ticket/20469#comment:15
https://trac.sagemath.org/ticket/20469#comment:15
<ul>
<li><strong>commit</strong>
changed from <em>f39c1399357d574109fb152cf456d8690fadde1b</em> to <em>738616df7442862e6062c78d5120e641b9461ebf</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=738616df7442862e6062c78d5120e641b9461ebf"><span class="icon"></span>738616d</a></td><td><code>Merge commit 'e9b6a594ae1e089b51b37081f35743402447a960' into public/algebras/ariki_koike_algebras-20469_2</code>
</td></tr></table>
TicketgitWed, 02 May 2018 04:38:11 GMTcommit changed
https://trac.sagemath.org/ticket/20469#comment:16
https://trac.sagemath.org/ticket/20469#comment:16
<ul>
<li><strong>commit</strong>
changed from <em>738616df7442862e6062c78d5120e641b9461ebf</em> to <em>08f90379eeb5ccb670d36e3cdbed2c07cdc78068</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="https://git.sagemath.org/sage.git/commit/?id=21b9e6b86c88df69114812e005bbc58cab6f61df"><span class="icon"></span>21b9e6b</a></td><td><code>Merge branch 'public/algebras/ariki_koike_algebras-20469' of git://trac.sagemath.org/sage into public/algebras/ariki_koike_algebras-20469</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=08f90379eeb5ccb670d36e3cdbed2c07cdc78068"><span class="icon"></span>08f9037</a></td><td><code>Fixing bugs and minor cleanup.</code>
</td></tr></table>
TickettscrimWed, 02 May 2018 04:40:39 GMT
https://trac.sagemath.org/ticket/20469#comment:17
https://trac.sagemath.org/ticket/20469#comment:17
<p>
I've found and fixed 2 bugs with the multiplication:
</p>
<ol><li>In <code>_product_LTwTv</code>, the coefficient <code>c</code> was not being multiplied in the second term.
</li><li>In <code>_Li_power</code>, the formula was suppose to be q<sup>-1</sup> (q - 1) = 1 - q<sup>-1</sup>, but instead it was q - q<sup>-1</sup>. This fixes the associativity test.
</li></ol><p>
Now all doctests are currently passing.
</p>
TicketgitWed, 02 May 2018 05:41:59 GMTcommit changed
https://trac.sagemath.org/ticket/20469#comment:18
https://trac.sagemath.org/ticket/20469#comment:18
<ul>
<li><strong>commit</strong>
changed from <em>08f90379eeb5ccb670d36e3cdbed2c07cdc78068</em> to <em>a6c89080e871eac1ab7d67d12855aee00d3183d3</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="https://git.sagemath.org/sage.git/commit/?id=7eafefd89eb4f1d5a0343bd6db0d08fafa2e10e4"><span class="icon"></span>7eafefd</a></td><td><code>Finished initial pass of cleanup.</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=f074dadaa0f51400152c52b91a97dc66153b95ca"><span class="icon"></span>f074dad</a></td><td><code>Some multiplication optimizations by not creating as many transient elements.</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=a6c89080e871eac1ab7d67d12855aee00d3183d3"><span class="icon"></span>a6c8908</a></td><td><code>A little bit more touchups and cosmetic changes.</code>
</td></tr></table>
TickettscrimWed, 30 May 2018 11:02:59 GMTstatus, milestone changed
https://trac.sagemath.org/ticket/20469#comment:19
https://trac.sagemath.org/ticket/20469#comment:19
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
<li><strong>milestone</strong>
changed from <em>sage-8.1</em> to <em>sage-8.3</em>
</li>
</ul>
<p>
Here is a version with 2 bases: the <code>T</code> basis given by BM and <code>LT</code> basis given by AK.
</p>
<p>
From some testing, the <code>T</code> basis implementation is (currently) clearly the better basis:
</p>
<pre class="wiki">sage: def test(B):
....: for b in B:
....: for bp in B:
....: b * bp
....:
sage: H = algebras.ArikiKoike(3, 3)
sage: LT = H.LT()
sage: T = H.T()
sage: %time test(LT.basis())
CPU times: user 4min 30s, sys: 1.64 s, total: 4min 31s
Wall time: 4min 31s
sage: %time test(T.basis())
CPU times: user 1min 40s, sys: 739 ms, total: 1min 41s
Wall time: 1min 40s
</pre><p>
In particular, this <code>LT</code> basis computation took over 5GB of RAM, whereas the <code>T</code> basis computation took less than 2GB. (The computation above involves all 26244 possible products.) The speed difference also holds for smaller dimensional spaces.
</p>
TickettscrimWed, 30 May 2018 11:03:33 GMTkeywords changed
https://trac.sagemath.org/ticket/20469#comment:20
https://trac.sagemath.org/ticket/20469#comment:20
<ul>
<li><strong>keywords</strong>
<em>days93.51</em> added
</li>
</ul>
TickettscrimThu, 31 May 2018 07:09:31 GMTcommit, branch changed
https://trac.sagemath.org/ticket/20469#comment:21
https://trac.sagemath.org/ticket/20469#comment:21
<ul>
<li><strong>commit</strong>
changed from <em>a6c89080e871eac1ab7d67d12855aee00d3183d3</em> to <em>6d1ac2c8f1e94ff3483b5f66182c43d061aec22b</em>
</li>
<li><strong>branch</strong>
changed from <em>public/algebras/ariki_koike_algebras-20469</em> to <em>public/algebras/ariki_koike_algebras_with_bases-20469</em>
</li>
</ul>
<p>
Last 10 new commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=429b0f9b6982ad682421ae42a458cc94cc897863"><span class="icon"></span>429b0f9</a></td><td><code>Fixing an error with multiplication of the T_i generators.</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=7317e86f7699a4e2fb6eaddd840d3029668d54b9"><span class="icon"></span>7317e86</a></td><td><code>Fixing multiplication the other way.</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=c504826002288ebb0620a86f1112ff58ef8426e6"><span class="icon"></span>c504826</a></td><td><code>Initial review</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=21822a22cccd8384914a8da12a4086e36472f97d"><span class="icon"></span>21822a2</a></td><td><code>Rewriting product code to avoid recursion</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=f366691e3928c3ef0c6f7ae668a0eeb5e6d26770"><span class="icon"></span>f366691</a></td><td><code>Fixing bugs and minor cleanup.</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=3af6dcc7ca43fef1c8ccc4864a5f1a3c67f871e7"><span class="icon"></span>3af6dcc</a></td><td><code>Finished initial pass of cleanup.</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=59d95836a472f78b70ada5b5c1a91a38c6c80060"><span class="icon"></span>59d9583</a></td><td><code>Some multiplication optimizations by not creating as many transient elements.</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=3e94feae4edc10cc9a92c4e92007d109a4811d0a"><span class="icon"></span>3e94fea</a></td><td><code>A little bit more touchups and cosmetic changes.</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=1d92cb71b3d6c5767282dffa1d15ae7d33085a82"><span class="icon"></span>1d92cb7</a></td><td><code>Implementation of T basis following [BM1997]_.</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=6d1ac2c8f1e94ff3483b5f66182c43d061aec22b"><span class="icon"></span>6d1ac2c</a></td><td><code>Use cartesian_product as the indices for the basis.</code>
</td></tr></table>
TicketgitThu, 31 May 2018 15:14:03 GMTcommit changed
https://trac.sagemath.org/ticket/20469#comment:22
https://trac.sagemath.org/ticket/20469#comment:22
<ul>
<li><strong>commit</strong>
changed from <em>6d1ac2c8f1e94ff3483b5f66182c43d061aec22b</em> to <em>712a76a071c1910f8f102f179e47cf43cb770146</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="https://git.sagemath.org/sage.git/commit/?id=712a76a071c1910f8f102f179e47cf43cb770146"><span class="icon"></span>712a76a</a></td><td><code>Fixing documentation.</code>
</td></tr></table>
TicketgitFri, 01 Jun 2018 10:04:18 GMTcommit changed
https://trac.sagemath.org/ticket/20469#comment:23
https://trac.sagemath.org/ticket/20469#comment:23
<ul>
<li><strong>commit</strong>
changed from <em>712a76a071c1910f8f102f179e47cf43cb770146</em> to <em>829576c0e9f6136a0f921e9c69a49e1a5c087307</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="https://git.sagemath.org/sage.git/commit/?id=829576c0e9f6136a0f921e9c69a49e1a5c087307"><span class="icon"></span>829576c</a></td><td><code>Removing duplicate reference.</code>
</td></tr></table>
TicketgitFri, 01 Jun 2018 10:20:00 GMTcommit changed
https://trac.sagemath.org/ticket/20469#comment:24
https://trac.sagemath.org/ticket/20469#comment:24
<ul>
<li><strong>commit</strong>
changed from <em>829576c0e9f6136a0f921e9c69a49e1a5c087307</em> to <em>c8a9c2f468c6832750ba0898257fab53e7996192</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="https://git.sagemath.org/sage.git/commit/?id=c8a9c2f468c6832750ba0898257fab53e7996192"><span class="icon"></span>c8a9c2f</a></td><td><code>Last little tweaks to the documentation.</code>
</td></tr></table>
TicketvdelecroixFri, 03 Aug 2018 19:20:18 GMTmilestone changed
https://trac.sagemath.org/ticket/20469#comment:25
https://trac.sagemath.org/ticket/20469#comment:25
<ul>
<li><strong>milestone</strong>
changed from <em>sage-8.3</em> to <em>sage-8.4</em>
</li>
</ul>
<p>
update milestone 8.3 -> 8.4
</p>
TicketchapotonSat, 11 Aug 2018 18:57:55 GMT
https://trac.sagemath.org/ticket/20469#comment:26
https://trac.sagemath.org/ticket/20469#comment:26
<p>
some typos:
</p>
<pre class="wiki">OUPTUT
</pre><pre class="wiki">These element different by a power of `q` from the corresponding
</pre><pre class="wiki">an tuple
</pre><p>
missing <code>\</code> in
</p>
<pre class="wiki">+.. [BM1997] K. Bremke and G. Malle,
</pre>
TicketchapotonSat, 29 Sep 2018 12:52:31 GMTstatus changed
https://trac.sagemath.org/ticket/20469#comment:27
https://trac.sagemath.org/ticket/20469#comment:27
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
branch is red
</p>
TicketgitFri, 07 Dec 2018 19:46:47 GMTcommit changed
https://trac.sagemath.org/ticket/20469#comment:28
https://trac.sagemath.org/ticket/20469#comment:28
<ul>
<li><strong>commit</strong>
changed from <em>c8a9c2f468c6832750ba0898257fab53e7996192</em> to <em>ebb2c1b6ac2f6efa06cc76e3ce7fc55ff0be2e05</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="https://git.sagemath.org/sage.git/commit/?id=ebb2c1b6ac2f6efa06cc76e3ce7fc55ff0be2e05"><span class="icon"></span>ebb2c1b</a></td><td><code>Merge branch 'public/algebras/ariki_koike_algebras_with_bases-20469' in 8.5.b6</code>
</td></tr></table>
TicketgitFri, 07 Dec 2018 19:47:47 GMTcommit changed
https://trac.sagemath.org/ticket/20469#comment:29
https://trac.sagemath.org/ticket/20469#comment:29
<ul>
<li><strong>commit</strong>
changed from <em>ebb2c1b6ac2f6efa06cc76e3ce7fc55ff0be2e05</em> to <em>0a058b5ee014946497148939e53e6ffc9ecba67a</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="https://git.sagemath.org/sage.git/commit/?id=0a058b5ee014946497148939e53e6ffc9ecba67a"><span class="icon"></span>0a058b5</a></td><td><code>one detail</code>
</td></tr></table>
TicketchapotonFri, 07 Dec 2018 19:48:03 GMTstatus, milestone changed
https://trac.sagemath.org/ticket/20469#comment:30
https://trac.sagemath.org/ticket/20469#comment:30
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>milestone</strong>
changed from <em>sage-8.4</em> to <em>sage-8.5</em>
</li>
</ul>
TicketchapotonWed, 16 Jan 2019 07:39:52 GMTstatus changed
https://trac.sagemath.org/ticket/20469#comment:31
https://trac.sagemath.org/ticket/20469#comment:31
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
one failing doctest, see patchbot
</p>
TicketgitFri, 13 Mar 2020 11:08:34 GMTcommit changed
https://trac.sagemath.org/ticket/20469#comment:32
https://trac.sagemath.org/ticket/20469#comment:32
<ul>
<li><strong>commit</strong>
changed from <em>0a058b5ee014946497148939e53e6ffc9ecba67a</em> to <em>5aac3c21109cee43d1382e2d6ef04839b73e7b64</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="https://git.sagemath.org/sage.git/commit/?id=82da4c45986b6b399252e4386561a695eab508db"><span class="icon"></span>82da4c4</a></td><td><code>Merge branch 'public/algebras/ariki_koike_algebras_with_bases-20469' of git://trac.sagemath.org/sage into public/algebras/ariki_koike_algebras_with_bases-20469</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=5aac3c21109cee43d1382e2d6ef04839b73e7b64"><span class="icon"></span>5aac3c2</a></td><td><code>Fixing multiplication in the T basis. Other misc cleanup.</code>
</td></tr></table>
TickettscrimFri, 13 Mar 2020 11:12:02 GMTstatus changed
https://trac.sagemath.org/ticket/20469#comment:33
https://trac.sagemath.org/ticket/20469#comment:33
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
Thanks to Sebastian doing some very thorough testing in looking at changing the index set, I came across a subtle bug in the T multiplication. When performing the reduction of the T<sub>0</sub><sup>r</sup> in T<sub>k,a</sub>, we can have a T<sub>0</sub><sup>0</sup>, which we want to "represent" as T<sub>k,0</sub>, but this is defined as <code>1</code>. So we have lost track of the s<sub>k-1</sub> ... s<sub>1</sub> permutation. This has now been fixed.
</p>
TicketchapotonSat, 14 Mar 2020 19:23:04 GMT
https://trac.sagemath.org/ticket/20469#comment:34
https://trac.sagemath.org/ticket/20469#comment:34
<p>
There seems to be some missing <code>r"""</code> that cause 3 "invalid escape sequences", see patchbot report.
</p>
TicketgitSun, 15 Mar 2020 22:28:11 GMTcommit changed
https://trac.sagemath.org/ticket/20469#comment:35
https://trac.sagemath.org/ticket/20469#comment:35
<ul>
<li><strong>commit</strong>
changed from <em>5aac3c21109cee43d1382e2d6ef04839b73e7b64</em> to <em>9a12b94c1a28b60baa0d4d5b9fb91529d49cd82f</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="https://git.sagemath.org/sage.git/commit/?id=9a12b94c1a28b60baa0d4d5b9fb91529d49cd82f"><span class="icon"></span>9a12b94</a></td><td><code>Making things raw strings to fix invalid escape sequences.</code>
</td></tr></table>
TickettscrimSun, 15 Mar 2020 22:31:29 GMT
https://trac.sagemath.org/ticket/20469#comment:36
https://trac.sagemath.org/ticket/20469#comment:36
<p>
Thanks. Fixed.
</p>
TicketsoehmsTue, 17 Mar 2020 15:46:43 GMT
https://trac.sagemath.org/ticket/20469#comment:37
https://trac.sagemath.org/ticket/20469#comment:37
<p>
It seems that you missed to fix this:
</p>
<pre class="wiki">sage: H = algebras.ArikiKoike(3, 4)
sage: LT = H.LT()
sage: LT.inject_variables()
Defining L1, L2, L3, L4, T1, T2, T3
sage: LT._Li_power(2,4) == L2 * LT._Li_power(2,3)
False
</pre>
TickettscrimTue, 17 Mar 2020 22:46:37 GMT
https://trac.sagemath.org/ticket/20469#comment:38
https://trac.sagemath.org/ticket/20469#comment:38
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/20469#comment:37" title="Comment 37">soehms</a>:
</p>
<blockquote class="citation">
<p>
It seems that you missed to fix this:
</p>
<pre class="wiki">sage: H = algebras.ArikiKoike(3, 4)
sage: LT = H.LT()
sage: LT.inject_variables()
Defining L1, L2, L3, L4, T1, T2, T3
sage: LT._Li_power(2,4) == L2 * LT._Li_power(2,3)
False
</pre></blockquote>
<p>
I do not think there is need to fix that because <code>_Li_power</code> is only used in the internal multiplication, which ultimately cancels or resolves out the issues with not doing proper reduction of the the L<sub>i</sub><sup>k</sup>. By not doing as many resolutions (which can generate large number of terms), it should be faster. Should I add something to the <code>_Li_power</code> docstring about this or run some timings to confirm?
</p>
TicketsoehmsWed, 18 Mar 2020 11:06:19 GMT
https://trac.sagemath.org/ticket/20469#comment:39
https://trac.sagemath.org/ticket/20469#comment:39
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/20469#comment:38" title="Comment 38">tscrim</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/20469#comment:37" title="Comment 37">soehms</a>:
</p>
<blockquote class="citation">
<p>
It seems that you missed to fix this:
</p>
<pre class="wiki">sage: H = algebras.ArikiKoike(3, 4)
sage: LT = H.LT()
sage: LT.inject_variables()
Defining L1, L2, L3, L4, T1, T2, T3
sage: LT._Li_power(2,4) == L2 * LT._Li_power(2,3)
False
</pre></blockquote>
<p>
I do not think there is need to fix that because <code>_Li_power</code> is only used in the internal multiplication, which ultimately cancels or resolves out the issues with not doing proper reduction of the the L<sub>i</sub><sup>k</sup>. By not doing as many resolutions (which can generate large number of terms), it should be faster.
</p>
</blockquote>
<p>
Ah, I forgot about that explanation!
</p>
<blockquote class="citation">
<p>
Should I add something to the <code>_Li_power</code> docstring about this or run some timings to confirm?
</p>
</blockquote>
<p>
I think a comment on that would make sense, since <code>LT._Li_power(2,4) == L2**4</code> giving <code>False</code> is quite irritating.
</p>
TicketgitThu, 19 Mar 2020 00:07:26 GMTcommit changed
https://trac.sagemath.org/ticket/20469#comment:40
https://trac.sagemath.org/ticket/20469#comment:40
<ul>
<li><strong>commit</strong>
changed from <em>9a12b94c1a28b60baa0d4d5b9fb91529d49cd82f</em> to <em>ff1ad8647d1bca65f348db804383a71c39e2b724</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="https://git.sagemath.org/sage.git/commit/?id=ff1ad8647d1bca65f348db804383a71c39e2b724"><span class="icon"></span>ff1ad86</a></td><td><code>A hybrid approach to an _Li_power computation.</code>
</td></tr></table>
TickettscrimThu, 19 Mar 2020 00:09:48 GMT
https://trac.sagemath.org/ticket/20469#comment:41
https://trac.sagemath.org/ticket/20469#comment:41
<p>
I ran some timings to confirm my suspicions, and here is what I found:
</p>
<pre class="wiki">sage: def test(LT):
....: B = LT.basis()
....: for b in B:
....: for bp in B:
....: dummy = b * bp
sage: H = algebras.ArikiKoike(4, 2)
sage: LT = H.LT()
sage: %time test(LT)
CPU times: user 3.49 s, sys: 6.16 ms, total: 3.5 s
Wall time: 3.5 s
sage: H = algebras.ArikiKoike(5, 2)
sage: LT = H.LT()
sage: %time test(LT)
CPU times: user 2min 50s, sys: 446 ms, total: 2min 51s
Wall time: 2min 51s
</pre><p>
versus always resolving it out:
</p>
<pre class="wiki">sage: H = algebras.ArikiKoike(4, 2)
sage: LT = H.LT()
sage: %time test(LT)
CPU times: user 3.16 s, sys: 23.5 ms, total: 3.18 s
Wall time: 3.18 s
sage: H = algebras.ArikiKoike(5, 2)
sage: LT = H.LT()
sage: %time test(LT)
CPU times: user 3min 14s, sys: 463 ms, total: 3min 14s
Wall time: 3min 14s
</pre><p>
So it seems to be inconsistent with which one is better strangely enough. Memory-wise they seem to be similar. The latter is ~11% slower. So I implemented a hybrid approach and here is the timings for that:
</p>
<pre class="wiki">sage: H = algebras.ArikiKoike(4, 2)
sage: LT = H.LT()
sage: %time test(LT)
CPU times: user 3.27 s, sys: 25.4 ms, total: 3.29 s
Wall time: 3.33 s
sage: H = algebras.ArikiKoike(5, 2)
sage: LT = H.LT()
sage: %time test(LT)
CPU times: user 3min 17s, sys: 389 ms, total: 3min 17s
Wall time: 3min 17s
</pre><p>
So I think I will go with the hybrid, trying keep some of the benefits of both (less multiplication and strict correctness at intermediate steps). I suspect the last timing is a little skewed because I was doing a few other things on my computer at the time.
</p>
TicketsoehmsFri, 20 Mar 2020 20:47:28 GMT
https://trac.sagemath.org/ticket/20469#comment:42
https://trac.sagemath.org/ticket/20469#comment:42
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/20469#comment:41" title="Comment 41">tscrim</a>:
</p>
<blockquote class="citation">
<p>
So I think I will go with the hybrid, trying keep some of the benefits of both (less multiplication and strict correctness at intermediate steps). I suspect the last timing is a little skewed because I was doing a few other things on my computer at the time.
</p>
</blockquote>
<p>
Are you sure you want to keep the hybrid version? I repeated your test and the timing comparison was even worse.
</p>
<p>
What about the following suggestion: Rename <code>_Li_power</code> as something like <code>_prepare_Li_power</code> to avoid such irritation. In addition, leave your new test in the docstring returning <code>False</code> as an example that this method does not give the final result (but for this purpose you have to run it for <code>algebras.ArikiKoike(3, 4)</code>).
</p>
<p>
Furthermore, the local function <code>L</code> in <code>_Li_power</code> seems not to be used any more. Can't we delete it?
</p>
TickettscrimFri, 20 Mar 2020 21:46:00 GMT
https://trac.sagemath.org/ticket/20469#comment:43
https://trac.sagemath.org/ticket/20469#comment:43
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/20469#comment:42" title="Comment 42">soehms</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/20469#comment:41" title="Comment 41">tscrim</a>:
</p>
<blockquote class="citation">
<p>
So I think I will go with the hybrid, trying keep some of the benefits of both (less multiplication and strict correctness at intermediate steps). I suspect the last timing is a little skewed because I was doing a few other things on my computer at the time.
</p>
</blockquote>
<p>
Are you sure you want to keep the hybrid version? I repeated your test and the timing comparison was even worse.
</p>
</blockquote>
<p>
Which timings? I agree this will probably be worse than the previous version, but it cannot be worse than the fully-reduced-to-basis version.
</p>
<blockquote class="citation">
<p>
What about the following suggestion: Rename <code>_Li_power</code> as something like <code>_prepare_Li_power</code> to avoid such irritation. In addition, leave your new test in the docstring returning <code>False</code> as an example that this method does not give the final result (but for this purpose you have to run it for <code>algebras.ArikiKoike(3, 4)</code>).
</p>
</blockquote>
<p>
I think that name is less descriptive. Plus it gives the correct result, just not necessarily in the basis elements, which is okay for an internal function not visible to the standard user. So if we decide revert the change, then I think just a warning would be sufficient.
</p>
<blockquote class="citation">
<p>
Furthermore, the local function <code>L</code> in <code>_Li_power</code> seems not to be used any more. Can't we delete it?
</p>
</blockquote>
<p>
Yes, we can delete it.
</p>
TicketsoehmsSat, 21 Mar 2020 15:14:42 GMT
https://trac.sagemath.org/ticket/20469#comment:44
https://trac.sagemath.org/ticket/20469#comment:44
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/20469#comment:43" title="Comment 43">tscrim</a>:
</p>
<blockquote class="citation">
<p>
Which timings? I agree this will probably be worse than the previous version, but it cannot be worse than the fully-reduced-to-basis version.
</p>
</blockquote>
<p>
Of course, I meant in the comparison with the previous version!
</p>
<blockquote class="citation">
<p>
So if we decide revert the change, then I think just a warning would be sufficient.
</p>
</blockquote>
<p>
Agreed!
</p>
<p>
Once this is done from my point of view we can let the ticket pass.
</p>
TicketgitSun, 22 Mar 2020 22:43:56 GMTcommit changed
https://trac.sagemath.org/ticket/20469#comment:45
https://trac.sagemath.org/ticket/20469#comment:45
<ul>
<li><strong>commit</strong>
changed from <em>ff1ad8647d1bca65f348db804383a71c39e2b724</em> to <em>2e11e63d49686fc133ddfb221f01cbb6f8e67f50</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="https://git.sagemath.org/sage.git/commit/?id=2e11e63d49686fc133ddfb221f01cbb6f8e67f50"><span class="icon"></span>2e11e63</a></td><td><code>Reverting to original method for _Li_power and added warning.</code>
</td></tr></table>
TickettscrimSun, 22 Mar 2020 22:44:40 GMT
https://trac.sagemath.org/ticket/20469#comment:46
https://trac.sagemath.org/ticket/20469#comment:46
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/20469#comment:44" title="Comment 44">soehms</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/20469#comment:43" title="Comment 43">tscrim</a>:
</p>
<blockquote class="citation">
<p>
So if we decide revert the change, then I think just a warning would be sufficient.
</p>
</blockquote>
<p>
Agreed!
</p>
<p>
Once this is done from my point of view we can let the ticket pass.
</p>
</blockquote>
<p>
Done. Thank you! Please set to a final positive review if you are happy with my changes.
</p>
TicketgitMon, 23 Mar 2020 06:57:22 GMTcommit changed
https://trac.sagemath.org/ticket/20469#comment:47
https://trac.sagemath.org/ticket/20469#comment:47
<ul>
<li><strong>commit</strong>
changed from <em>2e11e63d49686fc133ddfb221f01cbb6f8e67f50</em> to <em>bbe4874c2e1b013020de51553be87b2448767cc4</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="https://git.sagemath.org/sage.git/commit/?id=ed667ccee09c6e0f088d2d84eefd6866344ba094"><span class="icon"></span>ed667cc</a></td><td><code>Merge branch 'public/algebras/ariki_koike_algebras_with_bases-20469' of git://trac.sagemath.org/sage into ariki_koike_alg_20469</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=bbe4874c2e1b013020de51553be87b2448767cc4"><span class="icon"></span>bbe4874</a></td><td><code>20469: fixed pyflakes hint</code>
</td></tr></table>
TicketsoehmsMon, 23 Mar 2020 07:00:44 GMTstatus, reviewer changed
https://trac.sagemath.org/ticket/20469#comment:48
https://trac.sagemath.org/ticket/20469#comment:48
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
<li><strong>reviewer</strong>
changed from <em>Andrew Mathas, Travis Scrimshaw</em> to <em>Andrew Mathas, Travis Scrimshaw, Sebastian Oehms</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/20469#comment:46" title="Comment 46">tscrim</a>:
</p>
<blockquote class="citation">
<p>
Done. Thank you! Please set to a final positive review if you are happy with my changes.
</p>
</blockquote>
<p>
Yes, I am (just fixed a patchbot hint)! Thanks, as well.
</p>
TicketgitMon, 23 Mar 2020 07:08:35 GMTstatus, commit changed
https://trac.sagemath.org/ticket/20469#comment:49
https://trac.sagemath.org/ticket/20469#comment:49
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_review</em>
</li>
<li><strong>commit</strong>
changed from <em>bbe4874c2e1b013020de51553be87b2448767cc4</em> to <em>daf777ec27554610ab39c5bbe31f74673238c58c</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1 and set ticket back to needs_review. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=daf777ec27554610ab39c5bbe31f74673238c58c"><span class="icon"></span>daf777e</a></td><td><code>20469: redundant local function `L` deleted</code>
</td></tr></table>
TickettscrimMon, 23 Mar 2020 08:19:29 GMTstatus changed
https://trac.sagemath.org/ticket/20469#comment:50
https://trac.sagemath.org/ticket/20469#comment:50
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
<p>
Thank you.
</p>
TickettscrimMon, 23 Mar 2020 08:19:34 GMTmilestone changed
https://trac.sagemath.org/ticket/20469#comment:51
https://trac.sagemath.org/ticket/20469#comment:51
<ul>
<li><strong>milestone</strong>
changed from <em>sage-8.5</em> to <em>sage-9.1</em>
</li>
</ul>
TicketvbraunSun, 29 Mar 2020 00:24:23 GMTstatus, branch changed; resolution set
https://trac.sagemath.org/ticket/20469#comment:52
https://trac.sagemath.org/ticket/20469#comment:52
<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/algebras/ariki_koike_algebras_with_bases-20469</em> to <em>daf777ec27554610ab39c5bbe31f74673238c58c</em>
</li>
</ul>
Ticket