Hey everyone who's following #14772,
I don't want to change the patch, which has the multiplication in a
GlobalOptions class, since it's just lifts the previous options up (a
standard dict). Thus any change should depend on #14772 IMO. I'm not
attached to having multiplication be a global option anyways and would be
happy with two separate parents and/or element classes.
Hey Darij,
On Sunday, July 14, 2013 12:09:02 AM UTC+5:30, Darij Grinberg wrote:
>
> Hi Nicolas, and hi all,
>
> > - +1 on a parent option:
> >
> > sage: PermutationGroup(..., action='left')
> >
> > Note that this is consistent with what we do for finite set maps:
> >
> > sage: M = FiniteSetMaps([1, 2, 3], action = 'right')
> >
> > Maybe PermutationGroupElement will need to take an option too, and a
> > decision will need to be taken for mixed products.
>
> I like this idea a lot, provided we can pull this off.
>
> One way to do it, of course, is by making the symmetric group algebra
> an AlgebraWithRealizations (like most combinatorial Hopf algebras),
> and implement the two different conventions as two different
> realizations of it, with the antipode map (g |-> g^{-1} for g in the
> group) serving as the coercion in both directions. This will lead to
> things working exactly as they should, *but* the coercion map involves
> inverting permutations and that might slow things down. Ideally, I'd
> want two distinct PermutationGroup classes differing only in their
> __mul__'s, without having the need to duplicate code or split into
> cases depending on left/rightness. Something like: if I put a method
> in the left version of the PermutationGroup class, then it
> automatically also works for the right version, but if the method
> internally depends on __mul__, I want it to be using the same __mul__
> in both classes, so when I call the method from the right class, it
> first converts into the left version, then applies the method written
> there, and then converts back into the right version. But, of course,
> I only want this for methods which *internally* depend on
> multiplication rather than for methods like "product" which *should*
> work differently on both sides. Do we have the right framework to
> formalize this and make this work? Or is what I'm describing misguided
> or self-contradictory?
I think you're hoping for too much. If you have an algorithm which
strongly depends on permutation multiplication done a certain way, we will
need 2 separate element classes, one which does the algorithm, and another
which converts and calls the algorithm (or hacked around using some
optional arguments which I'd be against).
Best,
Travis
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
