[sage-devel] Re: Enumeration of totally real fields, continued
I've started a new thread for this topic with a long discussion of where we are up to. I don't want to hijack the totally real fields thread too much because it is extremely important, even though ultimately some of these issues are tied up together. Bill. --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Putting FLINT in SAGE
On 9/14/07, Bill Hart [EMAIL PROTECTED] wrote: In actual fact, it should be possible for us to write efficient conversion routines in C for going from a FLINT polynomial object to an NTL polynomial object and vice versa (at the very least), so a partial transition to NTL is both possible and definitely advisable if SAGE is to safely transition to FLINT. In my opinion you make doing the above your absolutely top priority before everything else. I'm not sure, but I suspect it won't be terribly difficult for you -- in fact, it will probably be easy -- but it would probably be very difficult for me. If you create such conversion functions, then as you mention below it will be possible to base ZZ[x] implementation in SAGE on FLINT very soon, and just resort to NTL for all the other operations, then as you implement new functionality we just replace 2 or 3 lines of Cython with your new faster function, and the rest of SAGE remains unchanged. As further motiviation, if you don't do the above, i.e., write fast conversion functions, I could imagine SAGE doing ZZ[x] arithmetic using FLINT, but using BASE TEN STRINGS to convert back and forth to NTL for gcd, etc. Just the thought of that will probably disgust you so much that you wouldn't possibly let it happen :-). [[This paragraph was meant as a joke; I hope the humor comes through in email.]] Technically, a handful of indispensible high level NTL polynomial functions could be encapsulated in a FLINT interface and we could replace these NTL functions one by one as we find the time to develop them. That would enable SAGE to use FLINT without worrying about NTL at all for ZZ[x] arithmetic. If that would be useful, let me know and I'll make sure that happens. It's not much work if the number of functions is small. --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Putting FLINT in SAGE
On Sep 15, 2007, at 3:30 AM, William Stein wrote: On 9/14/07, Bill Hart [EMAIL PROTECTED] wrote: In actual fact, it should be possible for us to write efficient conversion routines in C for going from a FLINT polynomial object to an NTL polynomial object and vice versa (at the very least), so a partial transition to NTL is both possible and definitely advisable if SAGE is to safely transition to FLINT. In my opinion you make doing the above your absolutely top priority before everything else. I'm not sure, but I suspect it won't be terribly difficult for you -- in fact, it will probably be easy -- but it would probably be very difficult for me. If you create such conversion functions, then as you mention below it will be possible to base ZZ[x] implementation in SAGE on FLINT very soon, and just resort to NTL for all the other operations, then as you implement new functionality we just replace 2 or 3 lines of Cython with your new faster function, and the rest of SAGE remains unchanged. I agree with William S, this is the most important thing to do. But maybe consider doing it the other way around: continue to use NTL as the base implementation in SAGE for a while, and make SAGE convert objects to FLINT objects temporarily for arithmetic, if the objects are large enough to make it worthwhile. My main concern is that using fmpz_poly will kill the machine for certain kinds of sparse polynomials. For example if you create the polynomial x^100 + 2^100, then NTL is perfectly fine with that, but fmpz_poly will try to allocate a million coefficients with a million bits each. Boom. david --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Putting FLINT in SAGE
Something to discuss and work on at Sage Days 6, perhaps, since David and Bill and William (and I) will be there? John On 9/15/07, David Harvey [EMAIL PROTECTED] wrote: On Sep 15, 2007, at 3:30 AM, William Stein wrote: On 9/14/07, Bill Hart [EMAIL PROTECTED] wrote: In actual fact, it should be possible for us to write efficient conversion routines in C for going from a FLINT polynomial object to an NTL polynomial object and vice versa (at the very least), so a partial transition to NTL is both possible and definitely advisable if SAGE is to safely transition to FLINT. In my opinion you make doing the above your absolutely top priority before everything else. I'm not sure, but I suspect it won't be terribly difficult for you -- in fact, it will probably be easy -- but it would probably be very difficult for me. If you create such conversion functions, then as you mention below it will be possible to base ZZ[x] implementation in SAGE on FLINT very soon, and just resort to NTL for all the other operations, then as you implement new functionality we just replace 2 or 3 lines of Cython with your new faster function, and the rest of SAGE remains unchanged. I agree with William S, this is the most important thing to do. But maybe consider doing it the other way around: continue to use NTL as the base implementation in SAGE for a while, and make SAGE convert objects to FLINT objects temporarily for arithmetic, if the objects are large enough to make it worthwhile. My main concern is that using fmpz_poly will kill the machine for certain kinds of sparse polynomials. For example if you create the polynomial x^100 + 2^100, then NTL is perfectly fine with that, but fmpz_poly will try to allocate a million coefficients with a million bits each. Boom. david -- John Cremona --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Interactive cells, GUIs, javascript, ...
Yes, thanks, that example looks like it will help me a lot. Btw, before reading William's instructions, I ran it without the - python option and it seemed fine. Does the -python option just turn off the preparser? Cheers, Marshall On Sep 14, 7:52 pm, William Stein [EMAIL PROTECTED] wrote: On 9/14/07, alex clemesha [EMAIL PROTECTED] wrote: I just posted a cleaned-up example of AJAX-twisted.web2-SAGE here: http://sage.math.washington.edu/home/agc/simple_ajax_twisted_sage.py just getting your hands dirty by messing with examples is best, then go to the books / google and learn about the details of the code. The script above pretty much gives you the simplest possible example of how to combine the technologies that make up the SAGE notebook. There is a tiny README at the top of the file. Thanks! Great simple example. For the total newbie, the way to use it is to download simple_ajax_twisted_sage.py to a file on your computer, then type sage -python simple_ajax_twisted_sage.py and follow the directions, i.e. open your browser to localhost:8000. Make sure you aren't already running a sage notebook on that port. I'll put this in the SAGE_ROOT/examples directory so it comes with future versions of SAGE. 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Putting FLINT in SAGE
Could NTL square this object? At present Maxima seems to be used to square such a polynomial. True, even the representation of such an object using an fmpz_poly_t is impractical, which is why we will eventually fully implement mpz_poly. But I propose we do something different again: Let FLINT manage which type it chooses to use to represent a polynomial. In the long run FLINT will probably implement a sparse polynomial type which will probably look quite different, even to an mpz_poly. This seems like justification enough to have a type Z_poly_t, which will internally represent a polynomial using multiple different formats. Z_poly will then be a thin layer of logic which will determine which internal format to use and call FLINT functions appropriately. This would be pretty useful for FFT caching by the way. We could internally represent polynomials in ZmodF_poly FFT format. Hell, we could even represent polynomials in bit or byte packed KS format, long_poly format and GF2_poly format!! Obviously FLINT will just cache all formats that it converts a polynomial to and reuse them whenever it needs to. We just need to be careful to invalidate the cached data whenever a computation changes a polynomial. So I need to implement something like this. For now, in the absence of a fully implemented mpz_poly, one of the internal FLINT polynomial formats may as well be an NTL ZZX. Once we have this implemented, we can fiddle around with how FLINT does things at will without affecting SAGE. For now the default internal format can be an mpz_poly_t. But I have to wonder if this is the best format in the long run. Surely if we want to deal with sparse polynomials efficiently, in the end we are going to need to allow sparse polynomials to be built without them first being built as mpz_polys, otherwise too much time is already wasted initialising the polynomial. At any rate, those are implementation details SAGE need not care about for now (except to keep sparse polynomials in mind - one should ensure that SAGE never itself represents a polynomial in a sparse non- friendly way). Bill. On 15 Sep, 13:53, John Cremona [EMAIL PROTECTED] wrote: Something to discuss and work on at Sage Days 6, perhaps, since David and Bill and William (and I) will be there? John On 9/15/07, David Harvey [EMAIL PROTECTED] wrote: On Sep 15, 2007, at 3:30 AM, William Stein wrote: On 9/14/07, Bill Hart [EMAIL PROTECTED] wrote: In actual fact, it should be possible for us to write efficient conversion routines in C for going from a FLINT polynomial object to an NTL polynomial object and vice versa (at the very least), so a partial transition to NTL is both possible and definitely advisable if SAGE is to safely transition to FLINT. In my opinion you make doing the above your absolutely top priority before everything else. I'm not sure, but I suspect it won't be terribly difficult for you -- in fact, it will probably be easy -- but it would probably be very difficult for me. If you create such conversion functions, then as you mention below it will be possible to base ZZ[x] implementation in SAGE on FLINT very soon, and just resort to NTL for all the other operations, then as you implement new functionality we just replace 2 or 3 lines of Cython with your new faster function, and the rest of SAGE remains unchanged. I agree with William S, this is the most important thing to do. But maybe consider doing it the other way around: continue to use NTL as the base implementation in SAGE for a while, and make SAGE convert objects to FLINT objects temporarily for arithmetic, if the objects are large enough to make it worthwhile. My main concern is that using fmpz_poly will kill the machine for certain kinds of sparse polynomials. For example if you create the polynomial x^100 + 2^100, then NTL is perfectly fine with that, but fmpz_poly will try to allocate a million coefficients with a million bits each. Boom. david -- John Cremona --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Putting FLINT in SAGE
OK, here is an important question. The only way SAGE has of moving polynomials between Maxima, NTL, Pari, Magma, SINGULAR, etc, at present, is via text strings, yes? So this means that the *only* time SAGE will ever try to convert a polynomial from some other format to a FLINT format is when it knows the full text string for the polynomial, yes? This means that in particular SAGE *always* knows both the length and number of bits per coefficient of a polynomial in advance, right? And in particular, the representation of any polynomial in SAGE itself is always sparse friendly. If so, then I'm pretty sure I know how to do this without slowing SAGE down. Bill. --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Putting FLINT in SAGE
On Saturday 15 September 2007 10:47, Bill Hart wrote: OK, here is an important question. The only way SAGE has of moving polynomials between Maxima, NTL, Pari, Magma, SINGULAR, etc, at present, is via text strings, yes? Increasingly that is not true and it should be less true than it is. The NTL wrapper has been growing been better and better ways to get coefficients and entire polynomials in out. Primarily this comes from fast (where I don't mean record-breaking, but MUCH better than text strings) import/export from mpz_t to and from NTL. It would seem to me that such things would also be possible with Pari (and I think is already done to some extent) and singular (with the new shared library interface) as well. Magma seems a lost cause for fast conversion due to it's closed nature and maxima is ... well ... maxima. These are just my (possibly uninformed) opinions, but I think you definitely should not make any design decisions based on conversion via base-10 text. -- Joel --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Interactive cells, GUIs, javascript, ...
Marshall wrote: Recently I started using Mathematica 6 in the computer labs of some courses I teach, and I cannot help but be impressed. The new dynamic commands such as Manipulate are very impressive, and are perfect for teaching. I looked at Mathematica's new manipulate command and I am now wondering if it calculates the rendering data on-the-fly when the sliders are moved or does it precalculate the rendering data and then the sliders are used to navigate through this data? Ted --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Interactive cells, GUIs, javascript, ...
My impression is that recalculates on the fly, but until you stop (moving a slider for example) it tries to do quick-and-dirty computations and rendering. This is pretty clear if you manipulate a 3D graph of a function f(x,y,a) with a the parameter - it doesn't even draw the mesh until you let go of the slider. -MH On Sep 15, 10:51 am, Ted Kosan [EMAIL PROTECTED] wrote: Marshall wrote: Recently I started using Mathematica 6 in the computer labs of some courses I teach, and I cannot help but be impressed. The new dynamic commands such as Manipulate are very impressive, and are perfect for teaching. I looked at Mathematica's new manipulate command and I am now wondering if it calculates the rendering data on-the-fly when the sliders are moved or does it precalculate the rendering data and then the sliders are used to navigate through this data? Ted --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Putting FLINT in SAGE
OK, I think I can do this in a way that is agnostic regarding the way SAGE does things. FLINT will offer a polynomial format called Z_poly_t. You will be able to convert in and out via text strings, and obviously you will be able to get/set coefficients to a given mpz_t and unsigned/signed long. NTL doesn't offer any more than that, so this can't slow SAGE down. For the time being FLINT will also offer a function to convert in and out from an NTL ZZX. This will enable a smooth transition over to the new type. But basically this won't be needed for long because the new Z_poly_t type will encapsulate all of FLINT and NTL, in which case SAGE may as well do away with the NTL ZZX as a fundamental type since it won't be needed for anything. The only question is, does SAGE ever currently convert directly from an NTL ZZX to another NTL polynomial format without going via mpz_t's or some other non-NTL type of integer? And I presume the basic integer format in SAGE is not an NTL ZZ, but either an mpz_t or some kind of python or C integer depending on the size? So SAGE would never need to deal with ZZ's. Bill. --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Putting FLINT in SAGE
This is an interesting proposal. Would the user (of the Z_poly_t) have control over what underlying representation is chosen? How would it decide? Would there be automatic coercions from one type to another doing arithmetic? Would this slow the process to getting FLINT ready to go? Also, would NTL then be a build requirement for FLINT? Would that make FLINT into a C++ package? Or is this something on top of both? - Robert On Sep 15, 2007, at 9:24 AM, Bill Hart wrote: OK, I think I can do this in a way that is agnostic regarding the way SAGE does things. FLINT will offer a polynomial format called Z_poly_t. You will be able to convert in and out via text strings, and obviously you will be able to get/set coefficients to a given mpz_t and unsigned/signed long. NTL doesn't offer any more than that, so this can't slow SAGE down. For the time being FLINT will also offer a function to convert in and out from an NTL ZZX. This will enable a smooth transition over to the new type. But basically this won't be needed for long because the new Z_poly_t type will encapsulate all of FLINT and NTL, in which case SAGE may as well do away with the NTL ZZX as a fundamental type since it won't be needed for anything. The only question is, does SAGE ever currently convert directly from an NTL ZZX to another NTL polynomial format without going via mpz_t's or some other non-NTL type of integer? And I presume the basic integer format in SAGE is not an NTL ZZ, but either an mpz_t or some kind of python or C integer depending on the size? So SAGE would never need to deal with ZZ's. Bill. --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Putting FLINT in SAGE
All good questions. On 15 Sep, 18:26, Robert Bradshaw [EMAIL PROTECTED] wrote: This is an interesting proposal. Would the user (of the Z_poly_t) have control over what underlying representation is chosen? No. It would be automatic. How would it decide? At first it would make a decision solely based on whether or not memory allocation is likely to ask for too much memory when trying to do things the FLINT way. Because of the way fmpz_poly works, that's actually easy to implement. This will at least fix the problem David Harvey is worried about, which is a valid concern. Later on we'd have to add some heuristics for detecting sparse polynomials and polynomials with many small and a few very large coefficients, efficiently. I don't see any other way around it. Either SAGE has got to do this or FLINT has got to do it automatically. It's probably more efficient to have FLINT do it automatically. Would there be automatic coercions from one type to another doing arithmetic? Absolutely. But they would occur very rarely and be relatively efficient. There are already many automatic coercions that happen in FLINT's fmpz_poly module. Would this slow the process to getting FLINT ready to go? No. It's absolutely essential that we do something like this *before* FLINT is ready to go, or the problem David Harvey mentioned will become a major problem for SAGE. For the time being, I'll offer conversion functions to and from ZZX's, so SAGE can just treat a Z_poly_t as the FLINT polynomial type (it's a simple matter of doing a search and replace of fmpz_poly for Z_poly in your current pyrex file Robert) and away you go. That means I only have to implement this thin Z_poly layer for the functions you are currently working on putting into SAGE. Later I can add all of NTL's functionality to Z_poly, and then SAGE can do away with ZZX. But there's no requirement for that to happen immediately, and it's probably not wise until FLINT has undergone some more serious testing. But putting this thin layer over the NTL functions we don't currently implement is also not hard. Also, would NTL then be a build requirement for FLINT? It would only be a build requirement when building the Z_poly module (which is what SAGE would use). And only for the time being, until we implement all the functions SAGE needs from NTL. Would that make FLINT into a C++ package? Or is this something on top of both? I don't know how to link C code with C++ code easily without compiling FLINT with g++. But this is only a matter of changing one line in the FLINT makefile. We'd still be developing FLINT as a C library, since this is a temporary fix until we get all of mpz_poly implemented. That will replace NTL at which point we can go back to compiling it using gcc. I'm some of the way through implementing this Z_poly_t layer already. I can do a little tonight, then I have to take a break from it for a few days. But then I can finish it off. It is an easy project and should only take a couple of days to code. Bill. --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Putting FLINT in SAGE
On Sep 15, 8:16 pm, Bill Hart [EMAIL PROTECTED] wrote:
All good questions.
On 15 Sep, 18:26, Robert Bradshaw [EMAIL PROTECTED]
wrote:
This is an interesting proposal. Would the user (of the Z_poly_t)
have control over what underlying representation is chosen?
No. It would be automatic.
How would
it decide?
At first it would make a decision solely based on whether or not
memory allocation is likely to ask for too much memory when trying to
do things the FLINT way. Because of the way fmpz_poly works, that's
actually easy to implement. This will at least fix the problem David
Harvey is worried about, which is a valid concern.
Later on we'd have to add some heuristics for detecting sparse
polynomials and polynomials with many small and a few very large
coefficients, efficiently. I don't see any other way around it. Either
SAGE has got to do this or FLINT has got to do it automatically. It's
probably more efficient to have FLINT do it automatically.
Would there be automatic coercions from one type to
another doing arithmetic?
Absolutely. But they would occur very rarely and be relatively
efficient. There are already many automatic coercions that happen in
FLINT's fmpz_poly module.
Would this slow the process to getting
FLINT ready to go?
No. It's absolutely essential that we do something like this *before*
FLINT is ready to go, or the problem David Harvey mentioned will
become a major problem for SAGE.
For the time being, I'll offer conversion functions to and from ZZX's,
so SAGE can just treat a Z_poly_t as the FLINT polynomial type (it's a
simple matter of doing a search and replace of fmpz_poly for Z_poly in
your current pyrex file Robert) and away you go. That means I only
have to implement this thin Z_poly layer for the functions you are
currently working on putting into SAGE.
Later I can add all of NTL's functionality to Z_poly, and then SAGE
can do away with ZZX. But there's no requirement for that to happen
immediately, and it's probably not wise until FLINT has undergone some
more serious testing. But putting this thin layer over the NTL
functions we don't currently implement is also not hard.
Also, would NTL then be a build requirement for FLINT?
It would only be a build requirement when building the Z_poly module
(which is what SAGE would use). And only for the time being, until we
implement all the functions SAGE needs from NTL.
Would that
make FLINT into a C++ package? Or is this something on top of both?
I don't know how to link C code with C++ code easily without compiling
FLINT with g++.
Just do the following to the header files for FLINT:
#ifdef __cplusplus
extern C
{
#endif
. (the declaration of C-functions occurs
. here, e.g.:)
#ifdef __cplusplus
}
#endif
Then just include them from C++ as usual and call FLINT functions just
like in C.
But this is only a matter of changing one line in the
FLINT makefile. We'd still be developing FLINT as a C library, since
this is a temporary fix until we get all of mpz_poly implemented. That
will replace NTL at which point we can go back to compiling it using
gcc.
I'm some of the way through implementing this Z_poly_t layer already.
I can do a little tonight, then I have to take a break from it for a
few days. But then I can finish it off. It is an easy project and
should only take a couple of days to code.
Bill.
Let me know if you have some problems.
Cheers,
Michael
--~--~-~--~~~---~--~~
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/
-~--~~~~--~~--~--~---
[sage-devel] Re: Putting FLINT in SAGE
On Sep 15, 2007, at 11:54 AM, mabshoff wrote: On Sep 15, 8:16 pm, Bill Hart [EMAIL PROTECTED] wrote: All good questions. On 15 Sep, 18:26, Robert Bradshaw [EMAIL PROTECTED] wrote: This is an interesting proposal. Would the user (of the Z_poly_t) have control over what underlying representation is chosen? No. It would be automatic. Often the user might know properties of the polynomial it wants before the list of coefficients is even generated (let alone passed to FLINT). Perhaps you could do something like flags to pass into init2, which would construct the right thing at the beginning, but not be forced to stick with it. How would it decide? At first it would make a decision solely based on whether or not memory allocation is likely to ask for too much memory when trying to do things the FLINT way. Because of the way fmpz_poly works, that's actually easy to implement. This will at least fix the problem David Harvey is worried about, which is a valid concern. Later on we'd have to add some heuristics for detecting sparse polynomials and polynomials with many small and a few very large coefficients, efficiently. I don't see any other way around it. Either SAGE has got to do this or FLINT has got to do it automatically. It's probably more efficient to have FLINT do it automatically. Yes, I'll be glad to let you do all the hard work if you want :-). I would imagine constructing polynomials coefficient-by-coefficient (rather than being handed an mpz_t**) will be the most common way to get something from SAGE, so one would have to keep this in mind. Would there be automatic coercions from one type to another doing arithmetic? Absolutely. But they would occur very rarely and be relatively efficient. There are already many automatic coercions that happen in FLINT's fmpz_poly module. Would this slow the process to getting FLINT ready to go? No. It's absolutely essential that we do something like this *before* FLINT is ready to go, or the problem David Harvey mentioned will become a major problem for SAGE. For the time being, I'll offer conversion functions to and from ZZX's, so SAGE can just treat a Z_poly_t as the FLINT polynomial type (it's a simple matter of doing a search and replace of fmpz_poly for Z_poly in your current pyrex file Robert) and away you go. That means I only have to implement this thin Z_poly layer for the functions you are currently working on putting into SAGE. Later I can add all of NTL's functionality to Z_poly, and then SAGE can do away with ZZX. But there's no requirement for that to happen immediately, and it's probably not wise until FLINT has undergone some more serious testing. But putting this thin layer over the NTL functions we don't currently implement is also not hard. Well, you make it sound like it'll be a quick job, so that'll be good. I bet it'll make testing easier for you too--you can run the same Z_poly code and set a flag of whether to do NTL or [f]mpz_poly and make sure the output is verbatim identical (but faster :-). Also, would NTL then be a build requirement for FLINT? It would only be a build requirement when building the Z_poly module (which is what SAGE would use). And only for the time being, until we implement all the functions SAGE needs from NTL. Makes sense... One thing I really like about FLINT (that I've seen so far) is it is pure C, and is as easy to work with as gmp's mpz_t, etc. (unlike, say, NTL). --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Can you build FLINT?
On Aug 28, 2007, at 15:58 , William Stein wrote: In preparation for including FLINT in SAGE, I've created an experimental FLINT sage package. Try building it: ./sage -f -m flint-0.1.spkg If this works, do cd spkg/build/flint-0.1/src and try some of the test programs, e.g., ./Z_mpn-test A bit tardy, so I don't know if it's useful. The build succeeded (SAGE 2.8.4.2) on both G4 and Core 2 Duo. I ran all the tests, with the following results: Dual G5: === ZmodF_mul-test === Testing _ZmodF_mul_fft_split()... ok Testing _ZmodF_mul_fft_combine()... ok Testing _ZmodF_mul_threeway_reduce()... ok Testing ZmodF_mul_info_mul_plain()... ok Testing ZmodF_mul_info_mul_threeway()... FAIL! Testing ZmodF_mul_info_mul_fft()... ok At least one test FAILED! === long_extras-test === Testing z_mod_precomp()... ok Testing z_div2_precomp()... ok Testing z_mod2_precomp()... ok Testing z_ll_mod_precomp()... FAIL! Testing z_mulmod_precomp()... ok Testing z_mulmod2_precomp()... ok Testing z_powmod()... ok Testing z_powmod2()... ok Testing z_sqrtmod()... ok Testing z_cuberootmod()... ok Testing z_nextprime()... ok Testing z_CRT()... ok Testing z_issquarefree()... ok Testing z_factor_trial()... ok Testing z_factor_SQUFOF()... ok Testing z_factor()... ok At least one test FAILED! Core 2 Duo: === ZmodF_mul-test === Testing _ZmodF_mul_fft_split()... ok Testing _ZmodF_mul_fft_combine()... ok Testing _ZmodF_mul_threeway_reduce()... ok Testing ZmodF_mul_info_mul_plain()... ok Testing ZmodF_mul_info_mul_threeway()... FAIL! Testing ZmodF_mul_info_mul_fft()... ok At least one test FAILED! Justin -- Justin C. Walker, Curmudgeon at Large Institute for the Absorption of Federal Funds --- I'm beginning to like the cut of his jibberish. --- --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Can you build FLINT?
On Sep 15, 9:59 pm, Justin C. Walker [EMAIL PROTECTED] wrote: On Aug 28, 2007, at 15:58 , William Stein wrote: In preparation for including FLINT in SAGE, I've created an experimental FLINT sage package. Try building it: ./sage -f -m flint-0.1.spkg If this works, do cd spkg/build/flint-0.1/src and try some of the test programs, e.g., ./Z_mpn-test A bit tardy, so I don't know if it's useful. The build succeeded (SAGE 2.8.4.2) on both G4 and Core 2 Duo. I ran all the tests, with the following results: Dual G5: === ZmodF_mul-test === Testing _ZmodF_mul_fft_split()... ok Testing _ZmodF_mul_fft_combine()... ok Testing _ZmodF_mul_threeway_reduce()... ok Testing ZmodF_mul_info_mul_plain()... ok Testing ZmodF_mul_info_mul_threeway()... FAIL! Testing ZmodF_mul_info_mul_fft()... ok At least one test FAILED! === long_extras-test === Testing z_mod_precomp()... ok Testing z_div2_precomp()... ok Testing z_mod2_precomp()... ok Testing z_ll_mod_precomp()... FAIL! Testing z_mulmod_precomp()... ok Testing z_mulmod2_precomp()... ok Testing z_powmod()... ok Testing z_powmod2()... ok Testing z_sqrtmod()... ok Testing z_cuberootmod()... ok Testing z_nextprime()... ok Testing z_CRT()... ok Testing z_issquarefree()... ok Testing z_factor_trial()... ok Testing z_factor_SQUFOF()... ok Testing z_factor()... ok At least one test FAILED! Core 2 Duo: === ZmodF_mul-test === Testing _ZmodF_mul_fft_split()... ok Testing _ZmodF_mul_fft_combine()... ok Testing _ZmodF_mul_threeway_reduce()... ok Testing ZmodF_mul_info_mul_plain()... ok Testing ZmodF_mul_info_mul_threeway()... FAIL! Testing ZmodF_mul_info_mul_fft()... ok At least one test FAILED! Justin -- Justin C. Walker, Curmudgeon at Large Institute for the Absorption of Federal Funds --- I'm beginning to like the cut of his jibberish. --- I would be great if you can make us an updated spkg. I can do some testing/valgrinding with it this weekend. Cheers, Michael --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Can you build FLINT?
NOTE:
If you do hg_sage.pull() right now, it will put all the code
in needed to use flint mentioned below, but it will comment
out the line in SAGE_ROOT/devel/sage/setup.py to
actually build fmpz_poly (line 345).
So you can alternatively do hg_sage.pull(), then uncomment
line 345.
William
On 9/15/07, William Stein [EMAIL PROTECTED] wrote:
On 9/15/07, mabshoff [EMAIL PROTECTED] wrote:
I would be great if you can make us an updated spkg. I can do some
testing/valgrinding with it this weekend.
Done:
[EMAIL PROTECTED]:~$ sage -f -m flint-0.2.p1.spkg
...
Let me know if this doesn't build on any platform.
And to actually *try* it from SAGE, apply the hg patch here:
http://sage.math.washington.edu/home/robertwb/flint/
by typing
sage: hg_sage:
hg_sage.apply('http://sage.math.washington.edu/home/robertwb/flint/sage-flint.hg')
sage: hg_sage.merge()
sage: hg_sage.ci()
sage: quit
$ sage -br
sage: from sage.libs.flint.fmpz_poly import Fmpz_poly
sage: f = ZZ['x'](range(1000))
sage: time for _ in xrange(10^3): g = f*f
CPU times: user 0.89 s, sys: 0.00 s, total: 0.89 s
Wall time: 0.89
sage: f = Fmpz_poly(range(1000))
sage: time for _ in xrange(10^3): g = f*f
CPU times: user 0.16 s, sys: 0.00 s, total: 0.16 s
Wall time: 0.16
sage: 0.89/0.16
5.562500
sage: magma.eval('f := PolynomialRing(IntegerRing())![0..999];')
''
sage: magma.eval('time for i in [1..10^3] do g := f*f; end for;')
'Time: 2.340'
sage: magma.eval('time for i in [1..10^3] do g := f*f; end for;')
'Time: 2.340'
sage: 2.34/0.16
14.62500
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--~--~-~--~~~---~--~~
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/
-~--~~~~--~~--~--~---
[sage-devel] Re: Can you build FLINT?
Sorry to reply to my own post, but I fixed a build problem
on powerpc OS X, so now the instructions to try flint are:
$ sage -i flint-0.2.p2.spkg
$ sage
sage:
hg_sage.apply('http://sage.math.washington.edu/home/robertwb/flint/sage-flint.hg')
sage: hg_sage.merge()
sage: hg_sage.ci()
sage: quit
$ sage -br
sage: f = ZZ['x'](range(1000))
sage: time for _ in xrange(10^3): g = f*f
CPU times: user 0.89 s, sys: 0.00 s, total: 0.89 s
Wall time: 0.89
sage: from sage.libs.flint.fmpz_poly import Fmpz_poly
sage: f = Fmpz_poly(range(1000))
sage: time for _ in xrange(10^3): g = f*f
CPU times: user 0.16 s, sys: 0.00 s, total: 0.16 s
Wall time: 0.16
sage: 0.89/0.16
5.562500
WITH THE CAVEAT that on some systems you might have to
comment out line 345 of setup.py
William
On 9/15/07, William Stein [EMAIL PROTECTED] wrote:
NOTE:
If you do hg_sage.pull() right now, it will put all the code
in needed to use flint mentioned below, but it will comment
out the line in SAGE_ROOT/devel/sage/setup.py to
actually build fmpz_poly (line 345).
So you can alternatively do hg_sage.pull(), then uncomment
line 345.
William
On 9/15/07, William Stein [EMAIL PROTECTED] wrote:
On 9/15/07, mabshoff [EMAIL PROTECTED] wrote:
I would be great if you can make us an updated spkg. I can do some
testing/valgrinding with it this weekend.
Done:
[EMAIL PROTECTED]:~$ sage -f -m flint-0.2.p1.spkg
...
Let me know if this doesn't build on any platform.
And to actually *try* it from SAGE, apply the hg patch here:
http://sage.math.washington.edu/home/robertwb/flint/
by typing
sage: hg_sage:
hg_sage.apply('http://sage.math.washington.edu/home/robertwb/flint/sage-flint.hg')
sage: hg_sage.merge()
sage: hg_sage.ci()
sage: quit
$ sage -br
sage: from sage.libs.flint.fmpz_poly import Fmpz_poly
sage: f = ZZ['x'](range(1000))
sage: time for _ in xrange(10^3): g = f*f
CPU times: user 0.89 s, sys: 0.00 s, total: 0.89 s
Wall time: 0.89
sage: f = Fmpz_poly(range(1000))
sage: time for _ in xrange(10^3): g = f*f
CPU times: user 0.16 s, sys: 0.00 s, total: 0.16 s
Wall time: 0.16
sage: 0.89/0.16
5.562500
sage: magma.eval('f := PolynomialRing(IntegerRing())![0..999];')
''
sage: magma.eval('time for i in [1..10^3] do g := f*f; end for;')
'Time: 2.340'
sage: magma.eval('time for i in [1..10^3] do g := f*f; end for;')
'Time: 2.340'
sage: 2.34/0.16
14.62500
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--~--~-~--~~~---~--~~
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/
-~--~~~~--~~--~--~---
[sage-devel] Re: Can you build FLINT?
ON 32-bit linux, i.e., meccah.math.harvard.edu, I get the following errors when trying to be build FLINT: flint.h:126: warning: implicit declaration of function `__builtin_clzl' gcc -std=c99 -I/usr/include -I/home/was/sage-bdist/local/include/ -I/home/was/sage-bdist/local/include -funroll-loops -fexpensive-optimizations -fPIC -O3 -c mpz_poly.c -o mpz_poly.o In file included from mpz_poly.c:11: flint.h: In function `FLINT_BIT_COUNT': flint.h:126: warning: implicit declaration of function `__builtin_clzl' gcc -std=c99 -I/usr/include -I/home/was/sage-bdist/local/include/ -I/home/was/sage-bdist/local/include -funroll-loops -fexpensive-optimizations -fPIC -O3 -c ZmodF_poly.c -o ZmodF_poly.o In file included from ZmodF_poly.c:14: flint.h: In function `FLINT_BIT_COUNT': flint.h:126: warning: implicit declaration of function `__builtin_clzl' gcc -std=c99 -I/usr/include -I/home/was/sage-bdist/local/include/ -I/home/was/sage-bdist/local/include -funroll-loops -fexpensive-optimizations -fPIC -O3 Z_mpn-test.o test-support.o -o Z_mpn-test mpn_extras.o Z.o memory-manager.o Z_mpn.o ZmodF.o ZmodF_mul.o ZmodF_mul-tuning.o fmpz.o fmpz_poly.o mpz_poly-tuning.o mpz_poly.o ZmodF_poly.o -L/home/was/sage-bdist/local/lib/ -Lqd -lgmp -lpthread -lm Z_mpn.o(.text+0x663): In function `__Z_mpn_mul': : undefined reference to `__builtin_clzl' Z_mpn.o(.text+0x67c): In function `__Z_mpn_mul': : undefined reference to `__builtin_clzl' Z_mpn.o(.text+0x1667): In function `Z_mpn_mul_precomp_init': : undefined reference to `__builtin_clzl' Z_mpn.o(.text+0x19cc): In function `Z_mpn_mul_precomp': : undefined reference to `__builtin_clzl' Z_mpn.o(.text+0x1bad): In function `__Z_mul': : undefined reference to `__builtin_clzl' Z_mpn.o(.text+0x1bc6): more undefined references to `__builtin_clzl' follow collect2: ld returned 1 exit status make: *** [Z_mpn-test] Error 1 g++ -fPIC -shared -fPIC -o libflint.so mpn_extras.o Z.o memory-manager.o Z_mpn.o ZmodF.o ZmodF_mul.o ZmodF_mul-tuning.o fmpz.o fmpz_poly.o mpz_poly-tuning.o mpz_poly.o ZmodF_poly.o -lgmp --- FLINT then doesn't work: sage: sage: from sage.libs.flint.fmpz_poly import Fmpz_poly --- type 'exceptions.ImportError' Traceback (most recent call last) /home/was/sage-bdist/ipython console in module() type 'exceptions.ImportError': /home/was/sage-bdist/local/lib/libflint.so: undefined symbol: __builtin_clzl 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Can you build FLINT?
On Sep 15, 10:47 pm, William Stein [EMAIL PROTECTED] wrote: ON 32-bit linux, i.e., meccah.math.harvard.edu, I get the following errors when trying to be build FLINT: flint.h:126: warning: implicit declaration of function `__builtin_clzl' gcc -std=c99 -I/usr/include -I/home/was/sage-bdist/local/include/ -I/home/was/sage-bdist/local/include -funroll-loops -fexpensive-optimizations -fPIC -O3 -c mpz_poly.c -o mpz_poly.o In file included from mpz_poly.c:11: flint.h: In function `FLINT_BIT_COUNT': flint.h:126: warning: implicit declaration of function `__builtin_clzl' gcc -std=c99 -I/usr/include -I/home/was/sage-bdist/local/include/ -I/home/was/sage-bdist/local/include -funroll-loops -fexpensive-optimizations -fPIC -O3 -c ZmodF_poly.c -o ZmodF_poly.o In file included from ZmodF_poly.c:14: flint.h: In function `FLINT_BIT_COUNT': flint.h:126: warning: implicit declaration of function `__builtin_clzl' gcc -std=c99 -I/usr/include -I/home/was/sage-bdist/local/include/ -I/home/was/sage-bdist/local/include -funroll-loops -fexpensive-optimizations -fPIC -O3 Z_mpn-test.o test-support.o -o Z_mpn-test mpn_extras.o Z.o memory-manager.o Z_mpn.o ZmodF.o ZmodF_mul.o ZmodF_mul-tuning.o fmpz.o fmpz_poly.o mpz_poly-tuning.o mpz_poly.o ZmodF_poly.o -L/home/was/sage-bdist/local/lib/ -Lqd -lgmp -lpthread -lm Z_mpn.o(.text+0x663): In function `__Z_mpn_mul': : undefined reference to `__builtin_clzl' Z_mpn.o(.text+0x67c): In function `__Z_mpn_mul': : undefined reference to `__builtin_clzl' Z_mpn.o(.text+0x1667): In function `Z_mpn_mul_precomp_init': : undefined reference to `__builtin_clzl' Z_mpn.o(.text+0x19cc): In function `Z_mpn_mul_precomp': : undefined reference to `__builtin_clzl' Z_mpn.o(.text+0x1bad): In function `__Z_mul': : undefined reference to `__builtin_clzl' Z_mpn.o(.text+0x1bc6): more undefined references to `__builtin_clzl' follow collect2: ld returned 1 exit status make: *** [Z_mpn-test] Error 1 g++ -fPIC -shared -fPIC -o libflint.so mpn_extras.o Z.o memory-manager.o Z_mpn.o ZmodF.o ZmodF_mul.o ZmodF_mul-tuning.o fmpz.o fmpz_poly.o mpz_poly-tuning.o mpz_poly.o ZmodF_poly.o -lgmp Looks like a gcc issue (from http://sourceware.org/ml/libc-alpha/2005-12/msg00020.html): GCC 3.4 and greater provide __builtin_clz which can be used for a better and simpler implementation. This patch makes soft-fp use these built-in functions. meccah uses a gcc 3.3.5. Cheers, Michael --- FLINT then doesn't work: sage: sage: from sage.libs.flint.fmpz_poly import Fmpz_poly --- type 'exceptions.ImportError' Traceback (most recent call last) /home/was/sage-bdist/ipython console in module() type 'exceptions.ImportError': /home/was/sage-bdist/local/lib/libflint.so: undefined symbol: __builtin_clzl 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 2.8.3 on Solaris - A New Hope
After setting up my own Solaris 10 box on Opterons I tried again with Sage 2.8.4.2: Overall things work quite well, some issues are left but it looks like all of them can be fixed given some energy is spend in the area. I will build VMWare Images of Solaris 10 Opteron in the near future (before SD5, probably the day before as I know myself ;), so that other interested people can play with the same setup. Building the toolchain is not particularly hard (once you have done it a couple dozen times), but I assume that most people would gladly skip over that part of the setup. Solaris 10 on Opteron: toolchain: ../gcc-4.2.1/configure --with-ld=/usr/sfw/i386-sun-solaris2.10/bin/ld --with-as=/usr/sfw/bin/gas \ --prefix=/usr/local/gcc-4.2.1 --enable-languages=c,c++,fortran --with- gmp=/usr/local/gmp-4.2.2-32/ \ --with-mpfr=/usr/local/mpfr-2.2.1p2-32/ It is of utmost important to used GNU ld and as! Also: GNU binutils, the ones on Solaris don't work properly in many cases ### Issues: ### * libgcrypt-1.2.4 In src/tests/Makefile.in: LINK = $(LIBTOOL) --tag=CC --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \ $(AM_LDFLAGS) $(LDFLAGS) -lnsl -lsocket -lmp -lscf -lgen - ldoor -lmd -lgcc_s -L/lib/ -luutil -o $@ Bug in os installation: in /lib: missing link to libuutil.so from libuutil.so.1? * opencdk-0.5.9 In src/tests/Makefile.in: LINK = $(LIBTOOL) --tag=CC --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \ $(AM_LDFLAGS) $(LDFLAGS) \ -lnsl -lsocket -lmp -lscf -lgen -ldoor -lmd -lgcc_s -L/lib/ - luutil -o $@ * gnutls-1.6.3: unresolved problem: /bin/bash ../libtool --tag=CC --mode=link gcc -D_REENTRANT - D_THREAD_SAFE -Wno-pointer-sign -pipe -I/export/home/mabshoff/ sage-2.8.4.2/local/include -I/export/home/mabshoff/sage-2.8.4.2/local/ include -lnsl -lsocket -lmp -lscf -lgen -ldoor -lmd -lgcc_s -L/lib/ - luutil -o gnutls-serv serv-gaa.o serv.o common.o select.o ../lib/ libgnutls.la ../libextra/libgnutls-extra.la -L/export/home/mabshoff/ sage-2.8.4.2/local/lib -lgcrypt -L/export/home/mabshoff/sage-2.8.4.2/ local/lib -lgpg-error gcc -D_REENTRANT -D_THREAD_SAFE -Wno-pointer-sign -pipe -I/export/home/ mabshoff/sage-2.8.4.2/local/include -I/export/home/mabshoff/ sage-2.8.4.2/local/include -o .libs/gnutls-serv serv-gaa.o serv.o common.o select.o -lnsl -lsocket -lmp -lscf -lgen -ldoor -lmd -lgcc_s -L/lib/ -luutil ../lib/.libs/libgnutls.so -L/export/home/mabshoff/ sage-2.8.4.2/local/lib ../libextra/.libs/libgnutls-extra.so /export/ home/mabshoff/sage-2.8.4.2/spkg/build/gnutls-1.6.3/src/lib/.libs/ libgnutls.so -lz -lxnet /export/home/mabshoff/sage-2.8.4.2/local/lib/ libgcrypt.so /export/home/mabshoff/sage-2.8.4.2/local/lib/libgpg- error.so -Wl,--rpath -Wl,/export/home/mabshoff/sage-2.8.4.2/local/lib ../libextra/.libs/libgnutls-extra.so: undefined reference to [EMAIL PROTECTED]' ../libextra/.libs/libgnutls-extra.so: undefined reference to [EMAIL PROTECTED]' ../libextra/.libs/libgnutls-extra.so: undefined reference to [EMAIL PROTECTED]' ../libextra/.libs/libgnutls-extra.so: undefined reference to [EMAIL PROTECTED]' ../libextra/.libs/libgnutls-extra.so: undefined reference to [EMAIL PROTECTED]' ../libextra/.libs/libgnutls-extra.so: undefined reference to [EMAIL PROTECTED]' ../libextra/.libs/libgnutls-extra.so: undefined reference to [EMAIL PROTECTED]' ../libextra/.libs/libgnutls-extra.so: undefined reference to [EMAIL PROTECTED]' ../libextra/.libs/libgnutls-extra.so: undefined reference to [EMAIL PROTECTED]' Odd, because ntohs and so on are in -lsocket -lnls -lresovl - cc shooting across. Sun ld issue? * python: needs -lrt -laio -lmd for symbols sem_init() - bug in configure script. -lmd also fixes md5 import problem. problems with sockets - see below: * twisted: import socket fails running install_egg_info Writing /export/home/mabshoff/sage-2.8.4.2/local/lib/python2.5/site- packages/zope.interface-3.3.0-py2.5.egg-info Traceback (most recent call last): File setup.py, line 20, in module from twisted import copyright File ./twisted/__init__.py, line 26, in module from twisted.python import compat File ./twisted/python/compat.py, line 15, in module import sys, string, socket, struct File /export/home/mabshoff/sage-2.8.4.2/local/lib/python2.5/ socket.py, line 45, in module import _socket ImportError: No module named _socket Error: Subprocess exited with result 1 for project core Error installing Twisted networking framework import problem with md5 module, tls related. OpenSSL builds 64 bit per default. But -lmd fixes that * singular: singular Singular script in $SAGE_LOCAL/bin are busted, various examples fail with error message - needs investigation * sagelib: - workaround in devel/sage/sage/rings/stdint.h for Solaris is not need on Solaris 10 - workaround in devel/sage/sage/combinat/partitions_c.cc is not needed on Solaris 10: //#if defined(__sun) //extern long double fabsl (long double); //extern long double sinl (long double); //extern long double
