Fwd: [sage-devel] Re: AbelianGroup constructor can't handle its own elements
John Cremona
---------- Forwarded message ----------
From: Gonzalo Tornaria <torn...@math.utexas.edu>
Date: Sun, May 8, 2011 at 11:20 PM
Subject: [sage-devel] Re: AbelianGroup constructor can't handle its own elements
To: sage-...@googlegroups.com
Slightly unrelated, there is the following note at the top of
sage/algebras/group_algebra.py:
"""
-- It seems to be impossible to make this fit nicely with Sage's coercion
model. The problem is that (for example) if G is the additive group (ZZ,+),
and R = ZZ[G] is its group ring, then the integer 2 can be coerced into R
in two ways -- via G, or via the base ring -- and *the answers are
different*. In practice we get around this by preventing elements of G
coercing automatically into ZZ[G], which is a shame, but makes more sense
than preventing elements of the base ring doing so.
"""
I don't really understand the issue.
Does anybody know an explicit example where this would indeed be a problem?
I believe the whole point of a group algebra is to linearize G, i.e.
embed it into an R-module R[G]. With that in mind, the map from R to
R[G] seems less important, not more -- it is the R-action what matters
on that front. I think I'd rather sacrifice the automatic coercion
from R instead of the one from G if one of the two really has to go.
What do you think?
Gonzalo
--
To post to this group, send an email to sage-...@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Simon King
On 9 Mai, 00:34, John Cremona <john.crem...@gmail.com> wrote:
> """
> -- It seems to be impossible to make this fit nicely with Sage's coercion
> model. The problem is that (for example) if G is the additive group (ZZ,+),
> and R = ZZ[G] is its group ring, then the integer 2 can be coerced into R
> in two ways -- via G, or via the base ring -- and *the answers are
> different*. In practice we get around this by preventing elements of G
> coercing automatically into ZZ[G], which is a shame, but makes more sense
> than preventing elements of the base ring doing so.
> """
additive group, and in that sense we can define the group algebra A =
R[R]. And then, the argument is as follows:
1) In Sage, so far any ring has a base ring, and we always want a
coercion from the base ring into the ring.
2) The base ring of A is R, and hence what we would usually do is
coerce R into A via r --> r*1_A. Therefore, we must not coerce R into
A via r --> 1_R*r.
3) In order to be consistent, we must not coerce G into R[G], even if
G!=R.
> I don't really understand the issue.
>
> Does anybody know an explicit example where this would indeed be a problem?
> I believe the whole point of a group algebra is to linearize G, i.e.
> embed it into an R-module R[G]. With that in mind, the map from R to
> R[G] seems less important, not more -- it is the R-action what matters
> on that front. I think I'd rather sacrifice the automatic coercion
> from R instead of the one from G if one of the two really has to go.
> What do you think?
Ad 1):
I really don't see why we should insist on considering the base ring
as a *subring*. After all, when you have an R-algebra B that is not
unital, then you certainly have an action of R, but R can not
naturally be identified with a subring. So, why should there always be
a coercion from R into B?? As Gonzalo has pointed out, in order to
have an action it is not needed to have a coercion.
Ad 2):
This argument seems valid to me: *If* we decide to identify the given
R-action on the R-algebra A with the action obtained by coercing R
into A, then we must not simultaneously have a different coercion.
Ad 3):
I think this is valid as well: We should not say "we coerce the base
ring R into B=R[G] via r-->r*1_B if and only if R!=G".
So, I guess I agree with Gonzalo. If r is in R and g is in an additive
group G, then r*g should live in R[G], r*G.zero_element()+g should be
in R[G] as well, but r+g should always result in a coercion error.
By the way, should we not have a method G.neutral_element(), that
returns the zero element for an additive group but the one element for
a multiplicative group?
Cheers,
Simon
Simon King
On 9 Mai, 08:12, Simon King <simon.k...@uni-jena.de> wrote:
> ...
> group G, then r*g should live in R[G], r*G.zero_element()+g should be
> in R[G] as well, but r+g should always result in a coercion error.