Changes between Version 1 and Version 2 of Ticket #20469, comment 8
 Timestamp:
 07/12/16 23:28:31 (5 years ago)
Legend:
 Unmodified
 Added
 Removed
 Modified

Ticket #20469, comment 8
v1 v2 3 3 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 `....T_i L_k...` were being put into standard form "letterbyletter" (so changing the previous expression to `\sum ... L_m T_j...`) you sometimes ended up going around in circles by pushing a `T_i` past an `L_k` that then created a large power of some `L_m` that, when reduced, got you back to the previous situation. I have rewritten the `product_on_basis` 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". 4 4 5 On top of this I proved a formula for the expansion of `L_k^m` t at, 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 changed `L_k` to `q**{1k}*L_k`because this renormalisation is what is normally used in the literature as it works better with the combinatorics.5 On top of this I proved a formula for the expansion of `L_k^m` 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 `L_k` to `q**{1k}*L_k`, in [AK] notation, because this renormalisation is what is normally used in the literature as it works better with the combinatorics. 6 6 7 I have made a start at adding the documentation. As a result of e rescaling of the `L_k`'s quite a lot of doctests are currently failing, being off by the corresponding powers of `q`  I am happy to fix these but I left them in at this stageso that you can compare if you wish. I am also happy to fill out the documentation as I know this area quite well.7 I have made a start at adding the documentation. As a result of the rescaling of the `L_k`'s quite a lot of doctests are currently failing, being off by the corresponding power of `q`. 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. 8 8 9 9 Other issues that we could think about are: 10  whether to allow the two parameter version: `(T_iq1)(T_i+q2)=0`. robably quite painful as all of the product formulas will change11  whether to implement the degenerate algebras. This might be easy as it could be done as a derived class with slightly different `_product_LTwTv`, `_product_Tw_L`, and `_Li_power` methods )12  I think having a slightly shorter `_repr_` string would be a good idea: `ArikiKoike algebra of rank 5 andparameters q,u0,u2,u3` is enough I think13  implementing other bases? This is probably best left for another ticket...especially as I think that the realisations code requires that the same indexing sets be used10  whether to allow the two parameter version: `(T_iq1)(T_i+q2)=0`. Probably quite painful as all of the product formulas will change 11  whether to implement the degenerate algebras. This might be easy as it could be done as a derived class with slightly different `_product_LTwTv`, `_product_Tw_L`, and `_Li_power` methods 12  I think having a slightly shorter `_repr_` string would be a good idea: `ArikiKoike algebra of rank 5 with parameters q,u0,u2,u3` is enough I think 13  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(?) 14 14 15 15 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.