Thanks Anne for the follow-up and my apologies to all for any lack of diplomacy in my post. Andrew
On Thursday, 17 October 2013 18:01:56 UTC+2, Anne Schilling wrote: > > 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.
