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.
