This conversation was off-list, but should be on-list, so I'm pushing it there.
Forwarded Conversation Subject: number fields ------------------------ From: William Stein <[EMAIL PROTECTED]> To: David Roe <[EMAIL PROTECTED]>, "Joel B. Mohler" <[EMAIL PROTECTED]>, Robert Bradshaw <[EMAIL PROTECTED]>, Craig Citro <[EMAIL PROTECTED]> Date: Fri, Aug 31, 2007 at 5:40 PM Attachments: magma-algebraic_number_theory.pdf Hi David, Joel, Robert, and Craig, Just to let you know, Robert Bradshaw and I are spending some time rethinking how to implement algebraic number theory in SAGE. So if you guys are about to dive into doing something... stop and lets talk. This is mainly inspired by the fact that: (1) I'm teaching an algebraic number theory course starting Sept 24, and (2) The CMI workshophttps://mail.google.com/mail/help/gmail_video.html#utm_source=en-et-newfea2&utm_medium=et&utm_campaign=en is on computational arithmetic geometry in SAGE, and it will be good to get a clear sense of how far behind MAGMA we are in algebraic number theory. I think -- irregardless of all past discussion -- that MAGMA is *by far* the gold standard in algebraic number theory computation, and we had better be extremely well informed about how things work there before doing anything major. For starters, most interesting code out there in arithmetic algebraic geometry has been written against MAGMA, and porting it will be much easier if SAGE's algebraic number theory design is very similar (interface-wise at least). I've attached a pdf of the part of the MAGMA documentation that describes algebraic number fields -- it's 186 pages long. I'm going to just read through it before doing anything further in this direction. My hope is to come up with some sort of implementation plan that can be done in stages. (1) some initial refactoring with no major changes in functionality at all -- this would be to put the code more in line with the "interfaces" idea of David Roe from SD4, but without the overwhelming number of possibilities that are in his skeleton code (that he sent only to me), (2) implementation of rings of integers -- this is a critical thing missing from the current code, which I *need* for my class. (3) unit groups and class groups (same as 2) (4) fill out more interfaces given (1) (5) move on to other less core functionality, i.e., so that any feature listed in the magma pdf attached to this email is also available in SAGE. Also, support more interfaces/representations. William -------- From: William Stein <[EMAIL PROTECTED]> To: David Harvey <[EMAIL PROTECTED]> Date: Fri, Aug 31, 2007 at 5:41 PM Attachments: magma-algebraic_number_theory.pdf [Quoted text hidden] -------- From: David Harvey <[EMAIL PROTECTED]> To: William Stein <[EMAIL PROTECTED]> Date: Fri, Aug 31, 2007 at 6:52 PM Sure, I would be interested in helping with that. I think looking at Magma's approach is a good idea. But it sure is a lot of text to skim :-) david [Quoted text hidden] -------- From: William Stein <[EMAIL PROTECTED]> On 8/31/07, David Harvey <[EMAIL PROTECTED]> wrote: > Sure, I would be interested in helping with that. I think looking at > Magma's approach is a good idea. But it sure is a lot of text to > skim :-) Unfortunately, skimming pales in comparison to the difficult of actually implementing it :-) Also, I can already see ways to improve on what MAGMA does -- or at least explain things better. For example, they have a sentence "It is important to remember that Q is NOT a number field." -- with *no* further explanation. Has there been any more thought on whether or not a number field should be a purely abstract object, or should they all be embedded in the complexes by definition (i.e., by choosing a numerical approximation to a root of the poly, which could get computed on the fly if it matters via some well defined ad hoc rule, e.g., smallest root in some non-algebraic ordering)? William -------- From: David Harvey <[EMAIL PROTECTED]> On Aug 31, 2007, at 10:00 PM, William Stein wrote: > On 8/31/07, David Harvey <[EMAIL PROTECTED]> wrote: >> Sure, I would be interested in helping with that. I think looking at >> Magma's approach is a good idea. But it sure is a lot of text to >> skim :-) > > Unfortunately, skimming pales in comparison to the difficult of > actually implementing it :-) > > Also, I can already see ways to improve on what MAGMA does -- or > at least explain things better. For example, they have a sentence > "It is important to remember that Q is NOT a number field." -- with > *no* further > explanation. Yeah --- especially since in my mind Q definitely IS a number field. > Has there been any more thought on whether or not a number field > should be a purely abstract object, or should they all be embedded in > the complexes by definition (i.e., by choosing a numerical > approximation > to a root of the poly, which could get computed on the fly if it > matters via > some well defined ad hoc rule, e.g., smallest root in some non- > algebraic > ordering)? Well there was the crazy idea of insisting that all number fields came with an embedding, but the embedding doesn't have to be in C, in fact it can even be into *itself*. That way you sort of get the best of both worlds. david -------- From: Craig Citro <[EMAIL PROTECTED]> > Yeah --- especially since in my mind Q definitely IS a number field. > Yep, I agree -- Q should be a number field. Is there some functionality that MAGMA doesn't implement for Q that they do for other number fields? Why wouldn't they put basic stuff in place for Q? Or is there some situation where arithmetic is going to get slowed down? > Well there was the crazy idea of insisting that all number fields > came with an embedding, but the embedding doesn't have to be in C, > in fact it can even be into *itself*. That way you sort of get the > best of both worlds. > Maybe I'm missing something there, but how does "self-embedding" work to specify anything? -cc -------- From: David Harvey <[EMAIL PROTECTED]> On Aug 31, 2007, at 10:25 PM, Craig Citro wrote: >> Well there was the crazy idea of insisting that all number fields >> came with an embedding, but the embedding doesn't have to be in C, >> in fact it can even be into *itself*. That way you sort of get the >> best of both worlds. > > Maybe I'm missing something there, but how does "self-embedding" > work to specify anything? I think the idea is just that it lets you have a uniform interface, makes for simpler code. I mean sometimes you want your fields embedded in C, sometimes in \bar Q_p, and sometimes nowhere in particular. I'm proposing handling the last case by having an embedding from the field to itself (the identity map), so that *all* number fields come equipped with an embedding. david -------- From: Craig Citro <[EMAIL PROTECTED]> [Quoted text hidden]Oh, I understand. So you're saying that all number fields come with an embedding, but it just might be trivial. So then instead of having one big world that everything is embedded in (i.e. C), you could take a given large field F (C, or \bar Q_p, or even some other number field), and ask whether a given number field has an embedding into that fixed, or even which number fields have an embedding into F. Actually, I like that more than I thought I would at first ... it reminds me of the coercion model, where you gather bits of information as you go, and when you want to know about two different things, somehow look in the transitive closure of the information you've got to see whether or not they're connected. It also makes more sense from an intuitive level -- let's say you define a number field, and you want to check something under every embedding into C. So in this more flexible model, you define your number field with the trivial embedding, and then run a loop over all embeddings into C and perform your computation. Of course, you could still do this in the other model -- compose with each galois element, and then use the fixed embedding into C ... I think the system with the more flexible model is more intuitive ... or, at least, it is to me. ;) -cc -------- From: Robert Bradshaw <[EMAIL PROTECTED]> [Quoted text hidden]I like the (possibly trivial) embedding idea too. When thinking about all of this, I think it is important to consider how the coercion model will fit into it (as there will be potentially many canonical yet dynamically-defined coercions). Currently it handles the transitive closer from the "there exists an embedding of other into self" but not the other way around. Having pointers in both directions could be tricky. - Robert --~--~---------~--~----~------------~-------~--~----~ 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/ -~----------~----~----~----~------~----~------~--~---
