On 6/15/07, David Harvey <[EMAIL PROTECTED]> wrote: > On Fri, 15 Jun 2007, Joel B. Mohler wrote: > > 1) ntl.pyx split into subsidiary files: > > ntl_ZZ.pyx ntl_ZZX.pyx ntl_ZZ_p.pyx .... (There's about 8-10 of > > them). > > I think this is a great idea.
+1. The first version of the ntl wrapper was actually broken up like this, but I had to put it back together because I couldn't build NTL in shared library mode on cygwin, and the above design will totally *break* if NTL is built inn non-shared mode. Now that Cygwin isn't a problem, don't worry about this, and break it up. However, if you run into weird errors when doing this, it would be probably because ntl wasn't built shared (it should be always these days). > > 2) Naming can be confusing. I'm going to alias the ntl C classes with a > > suffix > > "_c" to clarify things. Hence ZZ is labeled ZZ_c, etc. > > I don't think it matters all too much what you call them as long as the > exported names are sensible. Agreed. > > 3) Embed the C++ class into the pyrex struct for the python class (i.e. > > don't > > store a pointer to ZZ_c, use the actual class). This is controversial, but > > it > > saves a malloc and it's a sensible C++ idiom which I've used successfully > > for > > the number field connection to NTL. > > If this works (in a technical sense), sounds great to me. Yep. > If you really are doing a complete rewrite of the ntl wrapper, one thing > I'd love you to keep in mind is NTL's global modulus business. I've never > been convinced that this was fixed properly in SAGE. It definitely can't hurt to triple check this. -- William --~--~---------~--~----~------------~-------~--~----~ 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/ -~----------~----~----~----~------~----~------~--~---
