On 3/16/07, David Harvey <[EMAIL PROTECTED]> wrote: > It's not just slowness (which as you say, still needs to be > demonstrated). Another issue is maintainability. If we can wrap C++ > directly in ntl.pyx, why have another C++ layer? For example, when I > was writing the fast ZZ<->mpz_t code a few weeks back, I needed to > touch three layers of code: Polynomial_integer_dense, ntl.pyx, and > ntl_wrap.cc. It was pretty annoying.
Yes, but in some cases the resulting code is vastly easier to read and to write -- this is definitely the case with the Linbox wrapper, but is probably not the case with the ntl wrapper. > > I'm trying to think about the math a little bit behind this too. > > It seems that > > I shouldn't need a denominator. Are there number fields that need > > to be defined > > in terms of a polynomial with rational coefficients? Or, does it > > have to do > > with the fact that the number field code insists on the polynomial > > being monic? > > All number fields can be defined in terms of a monic polynomial with > integer coefficients. Suppose you start with a defining polynomial > which is monic but has non-integral coefficients. Multiply the whole > polynomial by L^d, where d is the degree and L is the LCM of the > denominators of the coefficients. Then you can absorb L into the > variable. (Another way to say this is to take any generator of K/k > and then multiply it by an appropriate integer to make it an > algebraic integer.) > > On the other hand, the user should be allowed to make number fields > by polys with non-integral coefficients. Perhaps you want to > translate for them, to make the arithmetic fast and the user > experience transparent. Sounds like a pain though. I strongly encourage you to do this. MAGMA can do it, and it's a feature users really really appreciate. They *will* have to do it themselves a lot if you don't -- and it's better to have the pain happen once and be thought out, than have it happen often. > Of course to represent *elements* of the number field, you need > denominators. Probably best to represent elements using a polynomial > in Z[x], with a single denominator, which is I think what you've been > suggesting. I suspect Joel was really asking about this, and I agree with your suggestion. William --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] 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/ -~----------~----~----~----~------~----~------~--~---
