On 3/16/07, Martin Albrecht <[EMAIL PROTECTED]> wrote: > > 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. > > True, to provide NTL functionality for core SAGE objects those should vanish. > Though, some core SAGE objects might be implemented in Python and call a > Pyrex class handling NTL for them. Also libs/ntl could still exist as an NTL > shell. This is secondary but might come in handy somehow, I don't know.
The ntl.pyx file should never vanish. One of the main points of SAGE is that it provides an interpreter interface to a wide range of major open source math software. NTL is one of these pieses of major open source math software. The ntl.pyx file provides NTL with almost the same *semantics* as NTL. For this, the objects in ntl.pyx must stay mutable (since they are in ntl), and the file itself obviously should continue to exist. That said, as David H suggests objects like polynomials over ZZ, etc., would probably be best implemented by directly calling the NTL library instead of going through ntl.pyx. It is still not clear to me that the ntl_wrap.* structure is slower than anything else for ntl.pyx, since couldn't one inline everything and compile with a C++ compiler? I'm not saying it isn't slower, only that it isn't clear to me that it has to be slower. For example, for linbox I think it was a better approach, since writing the wrapper code in SageX is too complicated. The wrapper code for ntl has so far been simple enough, but perhaps only because we have only partially wrapped ntl -- much remains to be done. Also, and this is probably only important for Linbox, for Linbox I'm going to move linbox_wrap.* out of the SAGE core library and into the linbox-*.spkg. The file linbox_wrap.cpp takes forever to compile, so if I make it a separate library that gets compiled at linbox install time, when one is developing SAGE code (or typing "sage -ba"), you won't have to wait at all for any linbox compilation anymore. This doesn't solve the problem that modifying linbox_wrap* is slow, but one very rarely does that. On 3/16/07, Joel B. Mohler <[EMAIL PROTECTED]> wrote: > 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. Yes, agreed. This is how SAGE provides an interface to NTL that is conceptually very very similar to NTL itself. > 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. This makes good sense. > 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.) This is not possible at present. I don't think there is a fundamental reason for it not being possible, but maybe there is. (On some OS's you can hack something that will work, but on others the same thing wont work. ) The standard thing to do in such cases, which is actually very nicely object oriented, is to make a cdef'd class whose methods are all the functions you want to export, then instantiate one instance of that class in any file from which you want to call those methods. See ext/arith.pyx for an example. > 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 think that's a good idea. Probably put an underscore at the front of the name. > 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. I agree that this is a good idea. > 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. By Python code I guess you mean SageX code. Yes, this would be useful. > 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. No, do not make them immutable. The current ntl.pyx code is supposed to have the same semantics as the NTL library. 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/ -~----------~----~----~----~------~----~------~--~---
