Hey Nathann,
   The main reason why I stalled on the permutations input was mainly 
trying to figure out how to handle generalized permutations (a.k.a. 
bi-words, two-line arrays, in bijection with N-matrices) so the RS(K) 
examples will still work (and as a 2fer, getting the full RSK working), and 
I wanted to talk in particular with Nicolas and Florent about how to 
structure/refactor everything. The current version of 
trac_8392-check_permutation-ts.patch in the sage-combinat queue currently 
checks to make sure input is 1 to n, however I can base that patch on the 
#13742 patch. I can also get back immediately into finishing the above 
patch if you want too.

Best,
Travis


On Thursday, November 22, 2012 8:38:42 AM UTC-8, Nicolas M. Thiery wrote:
>
>         Hi Nathann, 
>
> On Thu, Nov 22, 2012 at 06:13:52AM -0800, Nathann Cohen wrote: 
> >    Vincent, Travis, Dima : there's a new patch at #13742. It does 
> nothing. It 
> >    just checks input. It adds tests and warnings. And I lost half a day 
> and a 
> >    lunch because of very bad work. 
> >    Feel free to edit the patch as you like. I just want to be sure I can 
> >    trust permutations when I build one. Honestly, for me the only good 
> >    solution is to remove Permutations from Sage and let everything 
> break. 
> >    Then say "if you need it, write it". 5 years of waiting for it to 
> happen 
> >    have not done much good. 
>
> Mike Hansen worked like hell back in 2007 to port 30k lines of code 
> from MuPAD-Combinat to Sage. Of course that was not perfect by far: 
> you can't achieve such a massive goal and get a clean result in such a 
> short time, especially when the proper infrastructure is not yet 
> there. And yes, it often takes more time to refactor code than to 
> write it from scratch once you have the proper infrastructure. But at 
> least we had something we could work and do our daily research work 
> with. Altogether Mike' work was a huge asset in the migration of our 
> community from MuPAD to Sage, which in the end has already led to 
> 200k+ of code, at lot of which being quite clean. 
>
> Yes Permutations, as they are, are quite crappy; we claimed that from 
> day one. I totally understand your frustration from having been myself 
> hit hard so often by so many other crappy spots from the original Sage 
> code. Still, I am grateful to the people who rushed so hard to write 
> *something* and make Sage happen. 
>
> Granted, the refactoring of all this code is frustratingly long. But 
> there are a *lot* of efforts going on and things are progressing, one 
> step at a time (thanks everybody for that!). This will eventually get 
> done. 
>
> And we should *not* remove that code in the meantime, because, as 
> crappy as it is, it still serves its purpose in waiting for something 
> better.  If you want to add big fat warnings and some sanity checks, 
> sure go ahead. But please be kind and unobtrusive to those who wrote 
> it and those who are working hard to improve it. 
>
> Cheers, 
>                                 Nicolas 
> -- 
> Nicolas M. Thi�ry "Isil" <nth...@users.sf.net <javascript:>> 
> http://Nicolas.Thiery.name/ 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/sage-combinat-devel/-/XDXt9Pf_Se4J.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to 
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sage-combinat-devel?hl=en.

Reply via email to