2008/8/29 David Joyner <[EMAIL PROTECTED]>:
>
> I agree AbelianGroups needs rewriting and has odd behavior in
> some cases.
>
> Incidently, here is what GAP does:
>
> gap> A := AbelianGroup([1,2,3]);
> <pc group of size 6 with 3 generators>
> gap> GeneratorsOfGroup(A);
> [ <identity> of ..., f1, f2 ]
> gap> A := AbelianGroup([2,1,3]);
> <pc group of size 6 with 3 generators>
> gap> GeneratorsOfGroup(A);
> [ f1, <identity> of ..., f2 ]
>
> This is kind of mid-way between what Sage does now and what you
> are proposing. Is implementing this behavior worth considering?
In fact that is almost what my current rewrite (with almost complete
support for additive groups -- so far) does. Any trivial gens display
as 0 (or 1 in multiplcative groups), but those names are still
reerved. So in your last example the gens would display as [f1,1,f3].
Although that looks a bit odd, it is consistent (The 2nd generator is
f2 and is 1; the 3rd is f3).
If I can finished getting additive groups to work with at least as
much functionality as we already have for multiplicative groups, I'll
put up a patch for discussion, as that will already be an enhancement.
But it's only putting off the day when it is all redone from scratch
(everything done in terms of smith and hermite forms of integer
matrices, such as in Cohen's book).
John
PS I hope you (David J) don't mind constructive criticism -- without
what you did 2+ years ago we would have nothing at all! But we do
need to be able to handle everything Magma does...
> E:=EllipticCurve([0,-1,1,0,0]); TorsionSubgroup(E);
Abelian Group isomorphic to Z/5
Defined on 1 generator
Relations:
5*$.1 = 0
> E:=EllipticCurve([0,-1,1,0,0]); T,f:=TorsionSubgroup(E);
> Set(T);
{
0,
T.1,
2*T.1,
3*T.1,
4*T.1
}
> {f(P): P in T};
{ (0 : 1 : 0), (0 : -1 : 1), (0 : 0 : 1), (1 : -1 : 1), (1 : 0 : 1) }
Here's a naturally multiplcative example where the abstract group is
still displayed in additive notation (which I don't mind).
> C;
Abelian Group isomorphic to Z/3
Defined on 1 generator
Relations:
3*C.1 = 0
> Set(C);
{
0,
C.1,
2*C.1
}
> {f(c): c in C};
{
Ideal
Two element generators:
2
$.2,
Principal Ideal
Generator:
1,
Ideal
Two element generators:
2
$.2 - 1
}
>
>
> On Fri, Aug 29, 2008 at 7:14 AM, John Cremona <[EMAIL PROTECTED]> wrote:
>>
>> The subject says it all really. Can anyone justify the following behaviour?
>>
>> sage: A=AbelianGroup([])
>> sage: A
>> Trivial Abelian Group
>> sage: A.list()
>> []
>> sage: list(A)
>> []
>> sage: A.gens()
>> ()
>>
>> sage: B=AbelianGroup([1])
>> sage: B
>> Multiplicative Abelian Group isomorphic to C1
>> sage: B.list()
>> [1]
>> sage: list(B)
>> [1]
>> sage: B.gens()
>> (f,)
>>
>> When you create an abelian group by giving a list of generators with
>> their orders, the constructor kills any generators of order 1 UNLESS
>> you give precisely one generator which has order 1:
>> sage: AbelianGroup([1])
>> Multiplicative Abelian Group isomorphic to C1
>> sage: AbelianGroup([1,1])
>> Trivial Abelian Group
>> sage: AbelianGroup([1,1,1])
>> Trivial Abelian Group
>>
>> Without going so far aw to completely rewrite AbelianGroups -- which
>> really does need doing -- I would propose to stop this quiet deletion
>> of (most) trivial generators. It can only cause confusion:
>> sage: AbelianGroup([2,3,2],names='abc').gens()
>> (a, b, c)
>> sage: AbelianGroup([2,1,2],names='abc').gens()
>> (a, b)
>> In the user's program -- where the orders of the generators will vary
>> at run-time this can only cause trouble.
>>
>> But this is only temporary until someone does a complete rewrite...
>>
>> John
>>
>> >
>>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
