[completions at places of number fields] So, one thing that SAGE should support is completing a number field at a place. The resulting object will be either RR, CC, Qp, or a p-adic extension field. I think that it should also include the data of which completion it is. This allows one to automatically coerce elements from the number field to the completion. This is one of the motivations for the notion of entry point I mentioned in the previous e-mail, though thinking about it now I realize that the description I gave needs to be modified for this case.
Because of this need for different completions to store their places, there is no longer a unique real field. Perhaps the best way to do this is to have a RealCompletionField that extends RealField. It would store a number field K and a real place v of K; it would then have an automatic coercion from K. One would have to manually cast an element of a RealCompletionField into RR. Similarly for ComplexCompletionField (I suppose I choose one of the conjugate embeddings arbitrarily) and pAdicCompletionField. David On 4/26/07, David Roe <[EMAIL PROTECTED]> wrote: > > In the course of thinking about coercion for p-adic rings, fields and > extensions, I've had some ideas about a different kind of coercion model to > use for SAGE. It would fit into the existing coercion model, though I can > see it motivating changes to the existing model. > > SAGE currently does quite well when coercing between different basic rings > (Integers to Rationals for example). Each ring R implements a _coerce_impl > function that takes an element of another ring S and either returns an > element of R or raises an error if that element cannot be coerced into R. > When there is a canonical morphism from S to R, this is fine. But if there > is no such canonical morphism from S to R, you have to either use the syntax > R(x), in which case it picks a default map (which may or may not be a ring > morphism), or you have to define a ring morphism f: S ---> R and apply it > explicitly. This last option gets to be quite inconvenient when working > with towers of extensions, or even worse, with extensions that are not > explicitly defined as relative extensions of each other (currently SAGE > cannot automatically coerce from GF(19^2) to GF(19^4)). Part of the issue > is existence of automorphisms. Magma has a solution for finite fields that > I think we can extend to an automatic coercion system that works more > broadly (Bosma, Cannon and Steele. Lattices of Compatibly Embedded Finite > Fields. J. of Symbolic Comp. Volume 24, Issue 3-4). > > SAGE would define a commutative diagram class. One could implement this > as an extension of a Graph, where vertices are labeled by Rings (or Groups, > Algebras, etc), and the edges are labelled by morphisms in the appropriate > category. I think one should also allow sections of injections and > surjections. In order to coerce between two rings that both lie in the > diagram, one just finds a path from one to the other, and applies the > morphisms in succession. > > There are a couple of nice benefits of this approach. First, one can > apply the methods of "Lattices of Compatibly Embedded Finite Fields" to > automatically grow a global coercion environment so that if a user does the > following: > sage: K.<a> = GF(19^2) > sage: L.<b> = GF(19^4) > sage: c = a + b > sage: c.parent() > Finite Field in b of size 19^4, > things work appropriately. > > One might even allow adding elements where neither field embeds into the > other, but there is a default field containing both (when both are Galois > extensions of a third field, for example). > sage: K.<a> = GF(19^6) > sage: L.<b> = GF(19^4) > sage: c = a + b > sage: c.parent() > Finite Field in ? of size 19^12. > > There are other benefits of such a coercion model: one can use Python's > with syntax to allow user defined coercion environments. > The user creates a bunch of rings. Some are defined as extensions or > subfields of others, yielding some a priori injections and sections of > injections. The user can then define some morphisms between them, and > package all of this data into a "coercion environment" (a layer on top of a > commutative diagram). For example, one could do the following: > sage: S.<x> = QQ[] > sage: R.<y> = QQ[] > sage: f = S.hom([y^2], R) > sage: E = CoercionEnvironment([R, S], [f]) > sage: with E: > ... z = x + y > ... w = z - x^2 > ... > sage: w > y + y^2 - y^4 > sage: w.parent() > Univariate Polynomial Ring in y over Rational Field > > A question remains with what to do with coercions from outside the > coercion environment to inside, or vice versa. Obviously, the answer can > differe depending on which diagram's morphisms one uses. One solution would > be to say that in these cases one uses the outer coercion environment (ie > the default global one and not E in the example above). Yet there are times > when it's convenient to be able to use mixed environments: for example, when > coercing a constant polynomial over ZZ into a number field (or a constant > polynomial over one number field into another number field in a coercion > diagram). Another idea I've had is the notion of an entry point. If your > diagram has an initial object (S in the diagram above), then one first tries > to coerce in the outer environment. If this fails, one tries to coerce to > the initial object in the outer environment, and from the initial object to > your desired ring. One can similarly define the notion of exit points with > terminal objects. I don't know what to do if there are multiple initial or > terminal objects (check them in an order given at creation time?). > > Should CoercionEnvironments be mutable or immutable? (I'm leaning toward > immutable, but if someone has a good reason otherwise...) > > Another unresolved issue for me is how __call__ and _coerce_ should behave > differently in a coercion environment. Should __call__ only exist at the > top, global level of coercion, possibly using _coerce_ from user defined > coercion environments to fill in gaps? Should the default choices of > embeddings for finite fields and unramified p-adic extensions use call or > coerce syntax? > > How can we make all of this fast and memory-friendly? I think the > category theory code will need some revision. In particular, there need to > be special cases of morphisms that are fast (finite field morphisms, number > field morphisms, polynomial ring morphisms, etc). The field morphisms would > probably be implemented as matrices over a ground field (often a prime > field, but not necessarily). > > Please let me know what you think of all of this, and if you have > ideas/suggestions/etc. I have a few spin-off things that I've been thinking > about that I'll write follow-up e-mails for. > > 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/ -~----------~----~----~----~------~----~------~--~---
