Hi all, I'd like to discuss this abelian group thing a bit further, from the point of view of design issues rather than algorithms.
Currently in SAGE the situation appears to be the following. An AbelianGroup represents a (not necessarily finite) abelian group whose structure is *known*; i.e. to even create the group object, you need to specify generators and invariants. In fact, even the parent class Group derives from ParentWithGens, so it seems to be impossible to define a "group" whose generators are unknown. What I want to be able to do is create an object representing an abelian group whose structure is *not* a priori known, i.e. is expensive to compute. This is analogous to, for example, creating a matrix by specifying the entries, and then later on asking for other information like the rank, which is an expensive computation, and is subsequently cached. The main example I'm interested in at the moment is: * The group of K-rational points on a jacobian of an algebraic curve over k, where k and K/k are finite fields. Other examples: * The class group of a number field. * The multiplicative group of Z/nZ. * Like the Jacobian example above, but with the fields not finite (e.g. the rational points on an elliptic curve over Q) In these examples, it is easy to describe the group law, and it is relatively easy to write down some elements of the group, but it is difficult (or even impossible!) to compute the structure of the group. Consider the example of an elliptic curve E over a finite field k. Currently, when I call E.abelian_group(), it tries to compute the structure and return that as an AbelianGroup: sage: F = GF(17) sage: E = EllipticCurve(F, [2, 5]) sage: E.abelian_group() (Multiplicative Abelian Group isomorphic to C18, ((5 : 2 : 1),)) But I would like to be able to call something like E.abstract_abelian_group() and have it just return something like an AbstractAbelianGroup object, whose elements are something like AbstractAbelianGroupElements. This operation doesn't attempt to compute the group structure at all. The elements should remember that they came from that elliptic curve, and I should be able to create elements (by specifying their co-ordinates), and I should be able to perform arithmetic on elements. The AbstractAbelianGroup class should then have generic implementations of things like finding orders of elements, computing the exponent of the group, computing the structure of the group, which are then cached. (The reason I'm starting this thread at all is because I want to come up with a sane way to put these kind of generic group algorithms into SAGE.) Somehow at the moment in SAGE it's very difficult to separate the "group structure" from the "elliptic curve" structure. For example, suppose I have an elliptic curve over Q, and I want to work with points defined over some number field K/Q. Currently I think the only option I have is to base extend the curve to K, because points need to "belong" to the curve. But mathematically that shouldn't be necessary; I should be able to talk about K-valued points of a curve over Q. If I base-extend to K, I lose the information that the curve was really defined over Q (which might make certain computations easier). So what I would like to be able to do is call E.group_over_field(K) which returns an abstract abelian group. Maybe what I really want is a "ParentWithoutGens" base class :-) I'm really unsure of how to proceed with this. Especially since there are difficult coercion issues lurking in the background. Any thoughts would be most appreciated. david --~--~---------~--~----~------------~-------~--~----~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---