On Sep 20, 2007, at 12:05 AM, Bill Hart wrote: > On 20 Sep, 06:39, Robert Bradshaw <[EMAIL PROTECTED]> > wrote: > >>> To define an abstract number field, something like K = >>> number_field(QQ, x^3-3*x^2+1) could work. Eventually one will >>> want to >>> be able to do adjoin(K, y^5+7*y-1), compositum(L, M), etc. >> >> Would/could these functions return lists too, if, say, the >> intersection of L and M was not Q? > > Yeah, thinking about it some more, I think these functions really only > make sense if everything is embedded in another field. In particular > they should make sense if everything is embedded in an algebraic > closure of Q.
Yes, but the idea is that the field both are embedded in could (in some cases) be automatically generated, or there would be a finite list of possibilities of compatibly embedding of L and M in to a larger field. > But one might need to specify the field they are embedded in, since > ideally number fields should be allowed to be specified with more than > one embedding. > > I suppose that one could limit the number of embeddings of K to 1 and > then just clone K and give the clone a different embedding. But > whatever means is used to clone K it should be able to specify an > isomorphism between the two copies so that one can easily go from the > elements of one embedding field to the other. For example it would be > nice to embed K into its Galois closure and then think of this as > being identified with a subfield of Q bar. This would require K to be > simultaneously embedded in Q bar and in the Galois closure of K. This is what I envision, and is more consistent with the philosophy of SAGE that objects should be immutable. Given an abstract number field K, one would then construct a number field K1 = K.with_embedding (map_from_k_to_L) which would be a new object. I envision embedding would be transitive, and arithmetic between K1 and L would result in elements of L, whereas arithmetic between K1 and K would yield elements of K. > Of course one's wish list always grows longer than one's lifespan and > ability to implement. Can't argue with that! --~--~---------~--~----~------------~-------~--~----~ 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/ -~----------~----~----~----~------~----~------~--~---
