On Sat, Mar 13, 2010 at 11:13:13AM +0100, Florent hivert wrote:
> > We probably do not have to worry much about that, since the issue will
> > most likely disappear with Javier's work on conjugacy classes. If I
> > remember well, the plan is to be able to do, for any (finite) group G:
> >
> > sage: G.conjugacy_classes()
> > sage: [ cc.representative() for cc in G.conjugacy_classes() ]
> > sage: [ cc.cardinality() for cc in G.conjugacy_classes() ]
> > sage: [ cc.cardinality() for cc in G.conjugacy_classes() ]
>
> Should one of these two be
> sage: G.conjugacy_classes().cardinality()
Oops, yes!
> > sage: [ list(cc) for cc in G.conjugacy_classes()
> >
> > (which is, up to syntax details, about how it's done in GAP).
>
> However, I'd like to choose a standard to make it coherent with
> the (j|r|h|l)_class(es)_representative
> we will have in semigroup.
Yup. It would be good to do as above.
> Doesn't this asks for support something like lazy
> set-partition/equivalence relation in sets/combinatorics ? Or is
> this over-design ?
Possibly so! Let's listen to the code; it will tell us what can /
needs to be factored out.
Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nthi...@users.sf.net>
http://Nicolas.Thiery.name/
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
