Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Fwd: [sage-devel] Re: AbelianGroup constructor can't handle its own elements
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
  3 messages - Collapse all  -  Translate all to Translated (View all originals)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
John Cremona  
View profile  
 More options May 8 2011, 6:34 pm
From: John Cremona <john.crem...@gmail.com>
Date: Sun, 8 May 2011 23:34:09 +0100
Local: Sun, May 8 2011 6:34 pm
Subject: Fwd: [sage-devel] Re: AbelianGroup constructor can't handle its own elements
Forwarded from sage-devel.


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Simon King  
View profile  
 More options May 9 2011, 2:12 am
From: Simon King <simon.k...@uni-jena.de>
Date: Sun, 8 May 2011 23:12:40 -0700 (PDT)
Local: Mon, May 9 2011 2:12 am
Subject: Re: Fwd: [sage-devel] Re: AbelianGroup constructor can't handle its own elements
Hi!

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.
> """

In other words, if R is an integral domain ring then it also is an
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 do think that in the algebra A above it would 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?

That means, we would have to break one of the three arguments above.

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


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Simon King  
View profile  
 More options May 9 2011, 2:16 am
From: Simon King <simon.k...@uni-jena.de>
Date: Sun, 8 May 2011 23:16:29 -0700 (PDT)
Local: Mon, May 9 2011 2:16 am
Subject: Re: Fwd: [sage-devel] Re: AbelianGroup constructor can't handle its own elements
PS:

On 9 Mai, 08:12, Simon King <simon.k...@uni-jena.de> wrote:

> ...
> 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.

Or rather: The attempt to add r with an element of R[G] should always
result in a coercion error.

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
End of messages
« Back to Discussions « Newer topic     Older topic »