Hello, On Tue, 14 Aug 2007 17:12:02 +0200 Martin Albrecht <[EMAIL PROTECTED]> wrote:
> > William Stein wrote: > > > I'll wait for the answers to the above questions. I would be > > > fine with including > > > scons in SAGE. I think it's already in one of the optional > > > packages (I can't remember > > > for sure though). It's just a little python program, after all. > > > > > > It would take an absolutely massive amount of convincing to even > > > begin to convince me to include the entire 17MB C++ boost library > > > in SAGE. Actually, the entire compiled (gcc-4.1, debian etch) boost library takes up 437 MB, with an additional 35 MB for header files. In order to compile PolyBori, we need only - 2 MB of header files, if we omit the python wrapper and the functionality implemented in python, - 4.5 MB of header files, and 768 K of libraries, if we include the python wrapper as well. Obviously, the header files are not needed at runtime, and only the 768 K library would be needed. For reference, scons takes about 3 MB and compiled libraries of PolyBoRi take up more than 20 MB. Do the numbers above still pose a problem for including PolyBoRi? On a side note, I haven't looked into how much of the original boost distribution (13 MB tar.bz2) do we need to build the 768 K library mentioned above.. > I think we can benefit in two ways from PolyBori > > 1.) just use it for GB calculations. This way we can just use the > existing Python-Boost wrapper, convert, calculate and convert back. > In this scenario we would just have to investigate which pieces of > boost we need. This is not desirable for several reasons. - The representation of these polynomials in other software is not efficient, and they run out of memory very quickly. - We lose the optimizations it provides for arithmetic, which are also very significant. - Conversion of polynomials between different formats might be a big penalty for anything other than toy examples. If possible we should go for the option below. > 2.) use PolyBori as the backend for the native SAGE datatype. So if a > user constructs > > F_2[x_1,...,x_n]/FieldIdeal > > he/she gets QuotientRingElement_polybori just like he/she sometimes > gets MPolynomial_libsingular now. If we are going to do that, we will > need to wrap PolyBori again anyway to match our expected interface. > However, in that case, we still want to allow/reimplement the native > boost-power interface because some highlevel code of PolyBoRi is > written in Python. If we can _replicate_ what is done using Boost > with Cython -- I know we can, the question is how long it takes -- > the highlevel-code would still work. So in this scenario we'll have > to wrap twice. After looking at the size of boost, it doesn't look like rewriting the C++/python wrapper of PolyBoRi would be necessary. I think it is also worth the trouble of including the boost-python interface, since it provides a very elegant and easy method of interfacing C++ [1]. I tried googling for ways of using cython with C++ and the code that came up was not very pleasant. [1] http://www.boost.org/libs/python/doc/tutorial/doc/html/index.html > I strongly favor the second option. I completely agree. :) Comments? Burcin --~--~---------~--~----~------------~-------~--~----~ 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/ -~----------~----~----~----~------~----~------~--~---
