Re: [sage-combinat-devel] Re: StandardTableaux broken
Hi Darij, I still have a sage-5.4.1 with all combinat patches up to december 2012 on another machine, and t.descents() does what I expect. I admit that descents is a bad name for this (these are the descents of the inverse permutation of the row reading in French convention, in French we use reculs ( = recoils, or backsteps), but it is traditional to use descents in English. Btw, the name major index comes from the military rank of McMahon (Foata and Schutzenberger called it the major's index) , so there is only one major index All the best, Jean-Yves Le mercredi 16 octobre 2013 22:07:38 UTC+2, Andrew Mathas a écrit : Hi Darij, I've not yet needed descent sets of tableaux in sage so I don't know what the code did previously or what it does now in this respect. I would hope, however, that a descents method for tableaux would return the descent set of a tableau, so if you have ensured that this is now happening I think that's great! Andrew On Wednesday, 16 October 2013 20:32:11 UTC+2, darijgrinberg wrote: Hello Jean-Yves, hello Andrew, I guess I should have something to say about this but I don't really understand what is happening. When I wrote the #7983 patch, I was being annoyed by the fact that there was no method on the Tableaux class computing what everyone in combinatorics calls the descents, whereas the descents() method on tableaux was computing something rather unrelated (that, moreover, depends only on the shape if the tableau is semistandard). I suspect the descents() method was some kind of helper function for Jack or H-L related code. Anyway, I decided to rename the old descents() method into a less ambiguous name and to make descents() compute the actual descents. But I've quickly got talked out of this, as this would deprecate some userbase code, so instead I added a standard_descents() method and left descents() untouched (only adding the warning to its doc). I was working on sage-main all the time. Now, Jean-Yves (who, as far as I understand, has been using sage-combinat) is saying he has been using descents() all the time and since he is talking about standard tableaux, I assume that function has been computing the actual descents rather than whatever it has been computing on sage-main. Does this mean that the descents() function on sage-combinat has been doing something completely different from that on sage-main all the time before my #7983 patch? That someone had done what I first had in mind (rename the old descents() and reuse the name for the actual descents) long ago, and now that my #7983 got merged in, the roles have switched? Either way, sorry for contributing to this muckup and thanks a lot for any help in understanding it. Best regards, Darij -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-combinat-devel] Re: StandardTableaux broken
Hi Jean-Yves and everyone, OK, so it seems that some patch on the sage-combinat queue as of sage-5.4.1 solved the descents() problem in a more radical way than my sage-main patch. When my patch got merged into sage-main, the sage-combinat page would no longer apply, and so descents() once again became the old weird faux-descents function, while the correct descents function was now named standard_descents(). I wish I could confirm this but there seems to be no way to see the sage-combinat patches without being on the queue, let alone to see the old patches that are no longer in the queue. Either way, we should think about descents() when we rewrite tableau.py. Best regards, Darij On Thu, Oct 17, 2013 at 2:06 AM, Jean-Yves Thibon jythi...@gmail.com wrote: Hi Darij, I still have a sage-5.4.1 with all combinat patches up to december 2012 on another machine, and t.descents() does what I expect. I admit that descents is a bad name for this (these are the descents of the inverse permutation of the row reading in French convention, in French we use reculs ( = recoils, or backsteps), but it is traditional to use descents in English. Btw, the name major index comes from the military rank of McMahon (Foata and Schutzenberger called it the major's index) , so there is only one major index All the best, Jean-Yves Le mercredi 16 octobre 2013 22:07:38 UTC+2, Andrew Mathas a écrit : Hi Darij, I've not yet needed descent sets of tableaux in sage so I don't know what the code did previously or what it does now in this respect. I would hope, however, that a descents method for tableaux would return the descent set of a tableau, so if you have ensured that this is now happening I think that's great! Andrew On Wednesday, 16 October 2013 20:32:11 UTC+2, darijgrinberg wrote: Hello Jean-Yves, hello Andrew, I guess I should have something to say about this but I don't really understand what is happening. When I wrote the #7983 patch, I was being annoyed by the fact that there was no method on the Tableaux class computing what everyone in combinatorics calls the descents, whereas the descents() method on tableaux was computing something rather unrelated (that, moreover, depends only on the shape if the tableau is semistandard). I suspect the descents() method was some kind of helper function for Jack or H-L related code. Anyway, I decided to rename the old descents() method into a less ambiguous name and to make descents() compute the actual descents. But I've quickly got talked out of this, as this would deprecate some userbase code, so instead I added a standard_descents() method and left descents() untouched (only adding the warning to its doc). I was working on sage-main all the time. Now, Jean-Yves (who, as far as I understand, has been using sage-combinat) is saying he has been using descents() all the time and since he is talking about standard tableaux, I assume that function has been computing the actual descents rather than whatever it has been computing on sage-main. Does this mean that the descents() function on sage-combinat has been doing something completely different from that on sage-main all the time before my #7983 patch? That someone had done what I first had in mind (rename the old descents() and reuse the name for the actual descents) long ago, and now that my #7983 got merged in, the roles have switched? Either way, sorry for contributing to this muckup and thanks a lot for any help in understanding it. Best regards, Darij -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-combinat-devel] Re: StandardTableaux broken
Perhaps I can add a couple of words to Andrew's answer: I guess that the short (but harsh) answer is that if you have code which relies upon some one else's code which is in the queue, but which is not yet merged into sage, then there is no guarantee that your code will work next year, or even tomorrow. Any code which is merged should still work or, at a minimum, it should provide useful error messages to help you sort out what is going wrong (but this is only guaranteed in the first year after the change). I have certainly had this problem with my own private code and with the code that I have languishing in the queue. It might be a misconception that code related to combinatorics is only in the sage-combinat queue. Most code is merged into sage and distributed with each release of sage. The sage-combinat queue is used to share code that is being developed among researchers and developers. This code can indeed change any time (some code might even be experimental). Hence, if you are interested in reliable code it is better not to apply the sage-combinat queue. To use only code in sage you can do hg qpop -a sage -br or alternatively change to sage-main. Also, since the development flow will soon change to git, the sage-combinat queue will most likely disappear soon and/or will be replaced by a git fork or git branches. This is forced upon us by the move to git, but it is a good opportunity to change part of our work flow that has not worked so well. For example, it might be good that under the git framework the linear queue will change into a much flatter framework (since many patches do not actually depend on each other). As I haven't used (or touched) the methods that you are having issues with I don't know whether they were just in the queue or whether they were already part of the official sage distribution. If these methods were already included in an official release then clearly the review process has not worked properly in this instance and you have a legitimate complaint. Looking at the patch queue, robinson_schensted_inverse was depreciated in trac8392 http://trac.sagemath.org/attachment/ticket/8392. It seems to have been replaced with RSK_inverse which just seems wrong to me: with tab-completion I don't see the need for random acronyms, even relatively common ones like this one. (This probably just reflects my own idiosyncrasies:) Part of the deprecations have been reverted in http://trac.sagemath.org/ticket/15142 Franco, Mike and I had also observed what Andrew just mentioned and asked the authors to revert part of their changes. I think the review process might not have worked so well recently. For big changes like this a discussion should be done before completely revamping the methods that already exist. Returning to the question of the descents method, irrespective of whether it is backwardly compatible, I think it should the descent set of a tableau is what any reasonable algebraic combinatorialist would expect this method to return. Anything else is implementation-bug and it should be fixed. I agree. Best, Anne -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-combinat-devel] Re: StandardTableaux broken
Hey Andrew and Jean-Yves, Looking at the patch queue, robinson_schensted_inverse was depreciated in trac8392 http://trac.sagemath.org/attachment/ticket/8392. It seems to have been replaced with RSK_inverse which just seems wrong to me: with tab-completion I don't see the need for random acronyms, even relatively common ones like this one. (This probably just reflects my own idiosyncrasies:) There is also robinson_schensted_knuth[_inverse] methods in the global namespace with #15142 http://trac.sagemath.org/ticket/15142. And to get an output as a word, use the output='word' option. Note that the output will be an honest word object, not a permutation since non-standard permutations can break some of Permutations methods. If it is indeed a standard permutation, you can use output='permutation'. Well, I have changed descents to standard_descents, but I still have problems with the next two lines of my file. I use robinson_schensted_inverse. I see that it is deprecated (and certainly it should be, it did not even return a correct result one year ago and I had to patch it). So, deprecated, OK, but it still exists, and returns a different type now. Instead of a word (as it should be) it returns a list of two lists. This is bad. I can easily replace w by w[1]. But this is still not a word, and my function had to compute its descent composition. So it fails. I replace w by Word(w[1]). It fails again, as words do not have anymore a descents_composition ... So it is now Word(w[1]).standard_permutation().descents_composition(), and so on ... I see two possibilities to simplify this. The first is we add a descents_composition() method to words which just calls self.standard_permutation().descents_composition() (or perhaps its own optimized computation). The second would be to give RSK_inverse a checkargument which only checks for standardness if True and passes it to permutation if ouput='permutation'. I'm in favor of the former. Best, Travis -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-combinat-devel] Re: StandardTableaux broken
Hi Darij, I've not yet needed descent sets of tableaux in sage so I don't know what the code did previously or what it does now in this respect. I would hope, however, that a descents method for tableaux would return the descent set of a tableau, so if you have ensured that this is now happening I think that's great! Andrew On Wednesday, 16 October 2013 20:32:11 UTC+2, darijgrinberg wrote: Hello Jean-Yves, hello Andrew, I guess I should have something to say about this but I don't really understand what is happening. When I wrote the #7983 patch, I was being annoyed by the fact that there was no method on the Tableaux class computing what everyone in combinatorics calls the descents, whereas the descents() method on tableaux was computing something rather unrelated (that, moreover, depends only on the shape if the tableau is semistandard). I suspect the descents() method was some kind of helper function for Jack or H-L related code. Anyway, I decided to rename the old descents() method into a less ambiguous name and to make descents() compute the actual descents. But I've quickly got talked out of this, as this would deprecate some userbase code, so instead I added a standard_descents() method and left descents() untouched (only adding the warning to its doc). I was working on sage-main all the time. Now, Jean-Yves (who, as far as I understand, has been using sage-combinat) is saying he has been using descents() all the time and since he is talking about standard tableaux, I assume that function has been computing the actual descents rather than whatever it has been computing on sage-main. Does this mean that the descents() function on sage-combinat has been doing something completely different from that on sage-main all the time before my #7983 patch? That someone had done what I first had in mind (rename the old descents() and reuse the name for the actual descents) long ago, and now that my #7983 got merged in, the roles have switched? Either way, sorry for contributing to this muckup and thanks a lot for any help in understanding it. Best regards, Darij -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
