On Mar 16, 2007, at 10:13 AM, Joel B. Mohler wrote:
> > Hi, > > Some of these matters were touched on in off-list conversations. > However, I > think it might be of more general interest. My motivation in these > things is > the movement of the number fields down to SageX and an obsession > with getting > them 'frickin fast' as Martin might say. > > Conceptually, it seems we need two levels of bindings between us > and NTL. One > of these is the python classes which directly encapsulate NTL > types. The other > layer is a .pxi file and maybe a few C++ helper functions to make > utilizing NTL > from other SageX classes super-simple. At the moment, the naming > schemes > between my .pxi stuff and the NTL names are a bit of mish-mash. I > enlarge on > these comments in what follows. > > One of the things I worked on (that David Harvey started) is faster > routines > from gmp mpz_t to NTL ZZ types. Sitting right on top of that is a > fast > conversion between a sage int and an NTL ZZ. The result seems > pleasing to me, > but I expect that there will be some tweaks when it gets into > public view. I'm > not sure what namespace to put these conversions in -- that's my > first question. > I wanted them as global functions in the ntl.pyx file, but I'm not > sure how to > make a global pyrex cdef function (Can you do it? It would seem > you have to > link to the .so generated by ntl.pyx.) An alternative: put a cdef > function into > the Integer class to fill a ZZ* struct and a cdef function into the > Integer_ring > to construct an integer from a ZZ*. Thoughts? > > I also think that we need to make a .pxi file for easy usage of the > NTL C++ > library from other pyrex classes. I have the beginnings of this in > my number > field patch (soon to be submitted). I think it needs more thought > though. In > particular, someone needs to think a bit about how to consistently > name-mangle > the overloaded C++ functions into a coherent library of functions > to use from > pyrex. I'm started with all this, but I think I'll want some input. > > There exist ntl_ZZ and ntl_ZZX (and some others) classes in > ntl.pyx. These > provide an excellent usage example of the NTL library. I believe > that Martin > wants these to be turned into python bindings for NTL. I think > that could be > very pretty and useful to us -- e.g.: I want to efficiently pass an > NTL type > through honest-to-goodness python code. These classes currently > are not > immutable (and I abused that in my code) which is inconsistent with > the rest of > SAGE. I guess they should be made immutable (???) and I need to > fix my code > when that occurs. > > That's enough for now! Hmmm I'm a bit confused. Here's what I imagine in my ideal world: (1) We have a .pxi file for "easy usage of the NTL C++ library from other pyrex classes", as you say above. (2) The Polynomial_integer_dense class is implemented in pyrex. Its member functions call NTL functions directly and work with NTL objects directly. In particular, the ntl.pyx file would no longer exist (except as repository history :-)), and neither would ntl_wrap.cc. Is (2) what you mean by "python classes which directly encapsulate NTL types"? david --~--~---------~--~----~------------~-------~--~----~ 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/ -~----------~----~----~----~------~----~------~--~---
