On Feb 23, 1:01 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> 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.
>
> Excellent! Also look at the combinatorics functionality in MAGMA and
> Maple...
>
> > 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.
This makes a lot of sense for things like permutation.order(),
permutation.descents(), etc, but not a lot of sense for "number of
permutations with no three ascents" or similar. Those should be
methods in PermutationGroup.
But in general, I second the "methods in class hierarchy" layout.
It's working well for EllipticCurves.
Thanks, Mike, for implementing much needed functionality!
Nick
--~--~---------~--~----~------------~-------~--~----~
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/
-~----------~----~----~----~------~----~------~--~---
