---------- Forwarded message ----------
From: Nicolas M. Thiery <[EMAIL PROTECTED]>
Date: Mar 28, 2007 1:10 PM
Subject: Re: Combinatorics in SAGE
To: [EMAIL PROTECTED]
Dear Mike,
My post (two weeks ago) to sage-devel was rejected. Could you please
forward it on my behalf?
Thanks in advance,
Best regards,
Nicolas
------------------------------------------------------------------------------
Dear Sage developers,
> > On 2/23/07, Mike Hansen <[EMAIL PROTECTED]> wrote:
> > > The last couple days I've been working on adding a fair amount of
> > > functionality to the combinat module of SAGE. Mostly, I'd like to get
> > > it roughly as feature-complete as mupad-combinat or combinatorica.
You are very welcome to get in touch with us
([EMAIL PROTECTED]), and see if we can share anything
(design, user interface, documentation, tests, ...), if not just for
those poor users that will want to switch from one system to another.
How much "man-year" do you expect to put on this project? I mean, it
took us 6 years to develop MuPAD-Combinat. But of course, reusing past
experience, one can hope to go quite faster.
> > > I was wondering the best way to go about integrating these changes
> > > into SAGE, specifically naming conventions. For example, there are
> > > about 75 functions that apply to permuations of the form [1,2,3].
> > > Right now, I just have them in permutation.py in combinat/ and am
> > > importing them all through all.py. Would it be better / more
> > > consistent to just have all.py import permuation and then call the
> > > routines through something like permutation.descents(p) ?
> > Yes, that would help a lot to not pollute the global namespace
> > too much. Alternatively, all functions on permutations could
> > be methods on PermutationGroupElements, which are defined
> > in sage/groups/perm_gps/. This would be a nice way of unifying
> > things a bit more, and would make a lot of sense.
I haven't yet checked out the SAGE documentation. Do you have a single
class PermutationGroupElements, or one for each size n?
In MuPAD-Combinat, we have one Dom::SymmetricGroup(n) for each size
n. So, we decided to put the functions on permutations in a separate
domain (e.g. class in MuPAD parlance) combinat::permutations, because
there are a lot of functions that apply to permutations of varying
size (e.g. take a permutation of size m, one of size n, and return a
permutation of size n+m). Also, in many cases, we manipulate
permutations of many different size, and it would not make sense to
instantiate the domain Dom::SymmetricGroup(n) for each of those sizes.
Of course, there are "back links" in Dom::SymmetricGroup(n), albeit
not done automatically yet. Ideally, there probably should be some
hierarchy of categories (abstract class) containing the functions for
manipulating permutations, and various domains for the different use
cases (permutations of a fixed size, with group structure,
permutations of varying size possibly with other structures, ...).
We are having similar issues with trees and tableaux, and are in the
process of reorganizing them accordingly. See in particular:
http://mupad-combinat.sourceforge.net/Wiki/Tableaux
We would love to discuss such issues with others. The axiom workshop
in June is certainly a good occasion for this.
Best regards,
Nicolas
--
Nicolas M. Thiéry "Isil" <[EMAIL PROTECTED]>
http://Nicolas.Thiery.name/
----- End forwarded message -----
--
Nicolas M. Thiéry "Isil" <[EMAIL PROTECTED]>
http://Nicolas.Thiery.name/
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
