[sage-devel] Re: sage-2.0
Congrats to everyone on the milestone! Regards, Ifti. ps: Installed fine on my Macbook pro. real64m36.574s user39m42.589s sys 15m47.636s On Sun, 28 Jan 2007, William Stein wrote: Hello, I have released SAGE-2.0. Enjoy!! -- 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.0
On 1/28/07, William Stein [EMAIL PROTECTED] wrote: Hello, I have released SAGE-2.0. Enjoy!! is it in a different location? tlon[src] wget http://sage.scipy.org/sage/dist/src/sage-2.0.tar --10:41:04-- http://sage.scipy.org/sage/dist/src/sage-2.0.tar = `sage-2.0.tar' Resolving sage.scipy.org... 216.62.213.231 Connecting to sage.scipy.org|216.62.213.231|:80... connected. HTTP request sent, awaiting response... 404 Not Found 10:41:04 ERROR 404: Not Found. Cheers, f --~--~-~--~~~---~--~~ 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.0
On 1/28/07, David Joyner [EMAIL PROTECTED] wrote: The scipy mirror is being updated as we speak. Should be done in a few minutes. It seems OK now, thanks. Downloading... f --~--~-~--~~~---~--~~ 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.0
On Sun, 28 Jan 2007 09:41:25 -0800, Fernando Perez [EMAIL PROTECTED] wrote: On 1/28/07, William Stein [EMAIL PROTECTED] wrote: Hello, I have released SAGE-2.0. Enjoy!! is it in a different location? I doubt the scipy mirror would have caught up yet, since I just released it. The canonical location is http://sage.math.washington.edu/sage tlon[src] wget http://sage.scipy.org/sage/dist/src/sage-2.0.tar --10:41:04-- http://sage.scipy.org/sage/dist/src/sage-2.0.tar = `sage-2.0.tar' Resolving sage.scipy.org... 216.62.213.231 Connecting to sage.scipy.org|216.62.213.231|:80... connected. HTTP request sent, awaiting response... 404 Not Found 10:41:04 ERROR 404: Not Found. Cheers, f --~--~-~--~~~---~--~~ 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.0 !
David Harvey wrote: FLINT is coming along well, but I don't know if I can get all of the following done before SAGE 2.0: (a) get FLINT to release 1.0 (b) move generic polynomial elements to sagex (c) write specialised Z[x] wrapper (i.e. write a derived class of generic polynomial element) which uses FLINT objects for basic arithmetic I'm reasonably sure (a) will be done by SAGE 2.0. I don't think I can get all three done though. It would be really wonderful if someone would volunteer to do (b), and hopefully have it done before I get to (c). There's little chance of (a) being done by SAGE 2.0. The latter is due for release in 4 weeks, whilst the former will not be ready by then. The thing that will be missing is polynomial gcd (which relies on polynomial division, which also hasn't been implemented). MAGMA holds the world record for the former, and we are not going to beat them with a last minute coding sprint. However, what will be done is FLINT 0.5. This will have polynomial multiplication and integer factoring. Out integer multiplication also happens to be somewhat faster than GMP's (GMP will later this year release an improved version which will probably soundly beat us - the intial figures I've seen look very promising). It occured to me that the best way to provide this stuff directly to SAGE, and improve a whole raft of other things is to include our code in the SAGE version of Pari. But it occurs to me (just now) that this might be ill advised, given that many SAGE objects are not implemented through Pari, but through NTL. Unfortunately, integrating our code into NTL is not an option. I'm happy if people think they can write wrappers etc in time, to have SAGE just work directly with FLINT objects. Polynomial multiplication should be working by Monday-ish. But how I proceed might depend on what people think about this. So, should I: a) Try and incorporate FLINT into the SAGE pari; or b) Keep writing FLINT and let someone else figure out how to incorporate FLINT directly. The advantage of (a) is that heaps of stuff gets sped up, since heaps of stuff in Pari is built on polynomial arithmetic. The disadvantage is that some NTL stuff will want to be changed over to Pari stuff in SAGE. The advantage of (b) is probably a faster end product and less work for me. The disadvantage is it only benefits basic arithmetic, i.e. factoring, polynomial multiplication and integer multiplication and stuff *in SAGE* that depends on any of the above. 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: sage-2.0 !
Putting stuff into Pari is not that hard. I understand the Pari codebase. But if everyone else is happy with b, then obviously it is less work for me. 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: sage-2.0 !
On Thu, 4 Jan 2007, William Stein wrote: Also, it will be tremendously exciting that the PARI included in SAGE will be much faster than the stand-alone PARI :-). This seems to be a trend --- PARI+SAGE, Pyrex+SAGE --- forking other projects and adding value! What's next? ;) Ifti. --~--~-~--~~~---~--~~ 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.0 !
On Thu, 04 Jan 2007 15:43:53 -0800, David Harvey [EMAIL PROTECTED] wrote: Perhaps William Stein is well-placed to offer an opinion on which of(a) and (b) would be easier, since he knows the SAGE codebase very well (!), and he has plenty of experience programming with PARI too.I've never programmed PARI, so it's difficult for me to tell. And Bill has never programmed SAGE, so it's difficult for him to compare too. It's crucial to do both (a) PARI integration and (b) native wrapping. This is somewhat analogous to: (a) build PARI to use GMP (b) build native SAGE types on top of the GMP types. It's important to do both. David Harvey's argument that the Flint build is currently not very robust is a good argument for do a minimal version of (b) first, e.g., make a FlintZZ ring and implement PolynomialRing(FlintZZ) with just some functionality, test it out, then work on something more ambitious once Flint gets out there and build tested on many platforms. Doing a minimal (b) is very safe. 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.0 !
On Jan 4, 2007, at 3:43 PM, David Harvey wrote: On Jan 4, 2007, at 6:03 PM, William Stein wrote: On Thu, 04 Jan 2007 13:40:19 -0800, Bill Hart [EMAIL PROTECTED] wrote: It occured to me that the best way to provide this stuff directly to SAGE, and improve a whole raft of other things is to include our code in the SAGE version of Pari. But it occurs to me (just now) that this might be ill advised, given that many SAGE objects are not implemented through Pari, but through NTL. Unfortunately, integrating our code into NTL is not an option. I'm happy if people think they can write wrappers etc in time, to have SAGE just work directly with FLINT objects. Polynomial multiplication should be working by Monday-ish. But how I proceed might depend on what people think about this. So, should I: a) Try and incorporate FLINT into the SAGE pari; or b) Keep writing FLINT and let someone else figure out how to incorporate FLINT directly. The advantage of (a) is that heaps of stuff gets sped up, since heaps of stuff in Pari is built on polynomial arithmetic. The disadvantage is that some NTL stuff will want to be changed over to Pari stuff in SAGE. The advantage of (b) is probably a faster end product and less work for me. The disadvantage is it only benefits basic arithmetic, i.e. factoring, polynomial multiplication and integer multiplication and stuff *in SAGE* that depends on any of the above. I greatly prefer (a). Less of SAGE uses NTL than you might think, and using PARI in those places is easier (generally using PARI for SAGE is quite easy). Also, it will be tremendously exciting that the PARI included in SAGE will be much faster than the stand-alone PARI :-). I definitely agree that (a) would be wonderful to have. Nevertheless, I think we should concentrate on (b) first. My reasoning is as follows. First of all, FLINT doesn't even really exist yet. We have a bunch of source files which maybe kind of compile on a bunch of systems, if you fiddle with the makefile a bit. And sometimes they multiply polynomials and integers really fast, and sometimes if you are lucky they don't even segfault, and in many cases they even get the correct answer. Second, we eventually want to have both (a) and (b). We want (a) because of the excellent reasons Bill mentioned above. We want (b) because it means less overhead for polynomial objects in SAGE. i.e. for exactly the same reason that SAGE uses mpz_t objects directly instead of using PARI integer objects. (Also, don't forget (c), which is to have FLINT as a standalone library that doesn't require either SAGE or PARI.) Third, I claim that (b) is going to be much easier to implement than (a). This is my own personal bias, because I can see step-by- step how it could be done; it is straightforward. PARI integration sounds much harder. For a start it's not even clear to me how we would be representing data. PARI already has its own data structure for representing polynomials. Are we supposed to rewrite our code to use its polynomial data type? Or do we convert between the formats on the fly? Or do we change PARI to use our data type? Is PARI designed to let you throw in new kinds of data structures and memory management strategies? Do we have to store our data on the PARI stack, or can we go with the heap, as our custom memory manager currently does? Perhaps William Stein is well-placed to offer an opinion on which of (a) and (b) would be easier, since he knows the SAGE codebase very well (!), and he has plenty of experience programming with PARI too. I've never programmed PARI, so it's difficult for me to tell. And Bill has never programmed SAGE, so it's difficult for him to compare too. If someone can convince me that I'm wrong about PARI integration being much more difficult, then I could be persuaded to change my mind. But if I'm right about that, then I reckon it is too early in the FLINT development cycle to consider a big project like integrating it into PARI. I would rather that we first do the easier job of getting a SAGE data type that wraps FLINT polynomials, and concentrate our development efforts on getting FLINT solid, more functional, better tested, more portable. And then later come back to PARI integration. I reiterate, eventually both (a) and (b) will happen. It's just a question of timing, and where our development resources are best aimed. David You beat me too it--I think (a) and (b) are not at all mutually exclusive, but it will probably pushing it to have the easier of the two by sage 2.0. I think (b) would be very straightforward--I don't know what the data structure is for FLINT, but I'd imagine there's get_coefficient(mpz_t*, size_t), set_coefficient(mpz_t*, size_t) (or similar variations), and the basic arithmetic that could be wrapped with pyrex very easily.
[sage-devel] Re: sage-2.0 !
Hi All, Just to chime in a little bit here. I prefer (a) (the integrate it into PARI option) because I'm currently working on a C/OpenMPI code to perform a bunch of the PARI linear algebra stuff in parallel systems. Should have flakey-half-way-working code by mid. Feb., but my target is to make many of the routines dropin replacements for many of the PARI routines. So, hopefully code that uses those routines will be easily parallelizable. By the way, if anyone is at the AMS-MAA joint meetings right now, leave me a message at the message board (email is kind of spotty here). --jason --- Jason Worth Martin Asst. Prof. of Mathematics James Madison University http://www.math.jmu.edu/~martin phone: (+1) 540-568-5101 fax: (+1) 540-568-6857 Ever my heart rises as we draw near the mountains. There is good rock here. -- Gimli, son of Gloin On 1/4/07, David Harvey [EMAIL PROTECTED] wrote: On Jan 4, 2007, at 6:57 PM, William Stein wrote: On Thu, 04 Jan 2007 15:43:53 -0800, David Harvey [EMAIL PROTECTED] wrote: (a). This is my own personal bias, because I can see step-by-step how it could bedone; it is straightforward. PARI integration sounds much harder. For a startit's not even clear to me how we would be representing data. PARI already hasits own data structure for representing polynomials. I'm not sure what Bill Hart had in mind, but the following (below) is what I have in mind when I imagine PARI/Flint integration. [] OK, so basically you're saying, find the part of PARI that gets called whenever polynomials need to be multiplied, add a line like if (size 42) ... which converts to FLINT format, runs the multiplication, and converts back to PARI format. So the integration you have in mind is not all that tight. I guess this would be doable, and I agree it shouldn't be too difficult. 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: sage-2.0 !
On Jan 4, 2007, at 4:40 PM, Bill Hart wrote: I'm happy if people think they can write wrappers etc in time, to have SAGE just work directly with FLINT objects. Polynomial multiplication should be working by Monday-ish. But how I proceed might depend on what people think about this. So, should I: a) Try and incorporate FLINT into the SAGE pari; or b) Keep writing FLINT and let someone else figure out how to incorporate FLINT directly. Clearly (b) is far easier. There exist people (such as myself :-)) who know the FLINT and SAGE codebases intimately. Forcefeeding things into PARI is going to be much harder, since we don't (as far as I am aware) have any PARI authors around (?). My vote is to start with (b), and come back to (a) later, when FLINT is looking more solid. 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: sage-2.0 !
Hi, I would be interested in helping with Kantor's ODE solver , although I don't know what that is. I have a long-term goal of replacing Mathematica with SAGE for our department's ODE and Calc III labs, but I don't think the time is right yet. -Marshall Hampton University of Minnesota, Duluth --~--~-~--~~~---~--~~ 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.0 !
On Wed, 03 Jan 2007 10:52:07 -0800, Hamptonio [EMAIL PROTECTED] wrote: I would be interested in helping with Kantor's ODE solver , although I don't know what that is. I have a long-term goal of replacing Mathematica with SAGE for our department's ODE and Calc III labs, but I don't think the time is right yet. The time is definitely not right yet, but with a lot of work it will definitely be possible for open source mathematics software (SAGE) to be a vibrant alternative. Josh -- could you write to sage-devel and [EMAIL PROTECTED] explaining what you've done so far with ODE solving, what needs to be done, and how another person's feedback, examples, etc., would be helpful? 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.0 !
On Wednesday 03 January 2007 19:04, William Stein wrote: Hello, I've updated the roadmap at http://sage.math.washington.edu:9002/sage_trac/roadmap to get us to sage-2.0 in a reasonable way. We have four weeks left until I want to release sage-2.0. These are the main non-optional tasks listed there. Can anyone volunteer to help on any of these? My plan was to * use NTL for larger finite extension fields + NTL build optimizations (SAGE's NTL is very slow compared to how fast it could be) * fix that PARI + Debian Sarge Build Problem * push some thesis code upstream (optional, will postpone if needed) I hope fast MPolynomial arithmetic (at least over fields) will be in SAGE 2.1. I am also happy to help out with bugfixes if time permits. Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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.0 !
On Jan 3, 2007, at 12:00 PM, David Harvey wrote: On Jan 3, 2007, at 1:04 PM, William Stein wrote: * Implement in SageX the following ring elements: * CC -- arbitrary precision complex numbers * IR -- interval arithmetic ring * k[x] -- polynomial ring over arbitrary ring * First version of FLINT (Hart and Harvey's C library) Hi, I notice you have listed polynomial ring over arbitrary ring. Pushing this down to sagex is a prerequisite for getting the Z[x] arithmetic in FLINT integrated into SAGE. FLINT is coming along well, but I don't know if I can get all of the following done before SAGE 2.0: (a) get FLINT to release 1.0 (b) move generic polynomial elements to sagex (c) write specialised Z[x] wrapper (i.e. write a derived class of generic polynomial element) which uses FLINT objects for basic arithmetic I'm reasonably sure (a) will be done by SAGE 2.0. I don't think I can get all three done though. It would be really wonderful if someone would volunteer to do (b), and hopefully have it done before I get to (c). David I'll do (b) - Robert --~--~-~--~~~---~--~~ 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.0
Check out http://sage.math.washington.edu:9002/sage_trac/ especially the roadmap. http://sage.math.washington.edu:9002/sage_trac/roadmap V. STABILITY 2. Look at all todo's in the code. Could someone write a script to scan through code, cull the todos and put it up on the wiki? (I'm useless at this sort of scripting.) Thanks! Ifti. --~--~-~--~~~---~--~~ 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.0
On Tue, 12 Dec 2006 18:53:03 -0800, Iftikhar Burhanuddin
[EMAIL PROTECTED] wrote:
Check out http://sage.math.washington.edu:9002/sage_trac/
especially the roadmap.
http://sage.math.washington.edu:9002/sage_trac/roadmap
V. STABILITY
2. Look at all todo's in the code.
Could someone write a script to scan through code, cull the todos and
put it up on the wiki? (I'm useless at this sort of scripting.)
Try this:
sage: search_sage('todo')
--~--~-~--~~~---~--~~
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/
-~--~~~~--~~--~--~---
