[sage-devel] Re: GMP 4.3.0
On 22 Apr, 01:57, David Harvey dmhar...@cims.nyu.edu wrote: And whatever happened to not reinventing the wheel? I suppose that's a Sage motto but not an MPIR one? The same argument applied to FLINT and zn_poly leads to curious conclusions. So which are you arguing MPIR should do. 1) Try and reuse as much code out there that is already written, i.e. port other people's code to the MPIR code base (which you complained about). 2) Do all the work from scratch and come up with our own new algorithms to improve the same functionality. You can't have this both ways. With regard to 1, we have so far reused: * Moller's GCD patches * Originally we used Jason Martin's and Pierrick Gaudry's patches (admittedly we found better code since then) * Some assembly code of a Japanese hacker * Bodrato and Zimmermann's Toom code (at least the LGPL components of this work) * Brian's MSVC port of GMP * Numerous patches available online for various build issues on various platforms We intend to use: * Paul Zimmermann's FFT code * More of Bodrato's LGPL Toom code With regard to 2 we have: * Written our own Toom sequence generator * Written our own assembly optimiser * Come up with a number of new innovations at the assembly level especially with regard to division by constants and combining functions together to push more bits through the CPU * Found an interesting way of tuning the asymptotically fast GCD code With regard to matching GMP feature for feature we need to: * Improve speed of assembly language code on systems other than K8 * Write a new optimised mul_basecase for K8 based on the optimal addmul_2 code we included in MPIR 1.1.0 - currently it is not used at all * Speed up the FFT * Add square and unbalanced Toom variants * Implement faster division by 1 and 2 limbs * Asymptotically fast XGCD * Asymptotically fast division * Optimise Toom 4 code Now, given that code for some of the above has been available for *years* under the GPL or LGPL v2+ and now appears in GMP 4.3.0 then I am sure you'll allow that it is not unreasonable to allow 6 months for us to catch up in all these areas. But tell me, would you rather have us: 1) Do all this stuff completely from scratch coming up with new algorithms for all the above 2) Port everyone's code that we can't use by rewriting it and make use of the new algorithms exposed in GMP, e.g. Montgomery's algorithm for division by 1 limb 3) Issue a GPL v3+ version of MPIR which just includes the various bits of GMP that do the above You seem to be after a 4th option 4) Go away and stop developing MPIR. Sorry, that is not going to happen, ever!! So which is it going to be? And are you going to help? Bill. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: GMP 4.3.0
On 22 Apr, 01:58, David Harvey dmhar...@cims.nyu.edu wrote: I am talking about the mpn-level interface, which is relevant for a lot of the things I work on. If it helps, we have made a commitment to implementing the full public GMP interface in MPIR, including the mpn level. As GMP developers now have an open repo it should be trivial for us to see what the public interface is going to be ahead of GMP releases, no? BTW, I applaud the fact that GMP development is now more open in this regard. I see something good has come of all this already. Bill. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: GMP 4.3.0
On 22 Apr, 02:02, David Harvey dmhar...@cims.nyu.edu wrote: Can someone show me a benchmark where MPIR is faster than GMP? I tried a few basic things and couldn't find any. Someone who knows the MPIR codebase better than me should be able to find something. Are you aware that our MPIRbench score on K8 is higher than GMP's? Our rsa bench is way ahead. We have *only* optimised for K8 at present and even there we still have quite a bit to do. Jason Moxham is now into about the 4th version of his assembly optimiser and from what I can tell, it is far more capable than the one you guys wrote. We'll soon have optimised code sequences for far more CPU's than GMP even currently distinguishes. In the Toom 7 region, MPIR is significantly ahead of GMP. Our GCD code is better tuned than GMP's. Other improvements pending, it should eventually be faster than GMP's. Our code base runs natively on some systems that it doesn't even run on GMP. That's an infinite improvement. But really, I'm a little annoyed that you try to lay this kind of pressure on us. You know GMP has had much fast code available for years. We finished sorting out build issues at MPIR 0.9.0 which was release on 10th January. So we have done all of the rest of the work on speeding things up in 3 months. How much did GMP get done in that same 3 months? How long has it taken to write all the GMP code to do all these nice new things it does? Seriously, it looks for all the world to me that you are intentionally trying to kick MPIR while it is down, knowing full well that a comparison is unfair at this point. I expect that by October/November this year we will match GMP feature for feature, and that will be regardless of whether another release is made. On top of that we'll have a whole load of new stuff GMP doesn't have. I promise you, we have some really, really nice stuff on the way, e.g. parallel code is one of the main new focuses, and development of that will start in about 4 weeks. Will you support us in October/November when there is a clear reason to do so? In the mean time, how about letting us get on with our work. Better still, how about contributing your improvements to *both* projects. Bill. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: GMP 4.3.0
Seriously, it looks for all the world to me that you are intentionally trying to kick MPIR while it is down, knowing full well that a comparison is unfair at this point. I expect that by October/November this year we will match GMP feature for feature, and that will be regardless of whether another release is made. On top of that we'll have a whole load of new stuff GMP doesn't have. I promise you, we have some really, really nice stuff on the way, e.g. parallel code is one of the main new focuses, and development of that will start in about 4 weeks. Will you support us in October/November when there is a clear reason to do so? In the mean time, how about letting us get on with our work. Better still, how about contributing your improvements to *both* projects. Bill, David, We're all friends here. Let's not let this escalate. Nick --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: GMP 4.3.0
I apologise if this seemed rude. I should have made the point more subtly. I'm just trying to deal with it in an open way. David has taken clear exception to the use of MPIR in Sage by default, and some of his points are valid for the time being. But I want to be clear that MPIR is not going away and that if David's intention is to try and stamp out MPIR now while it is still not completely clear what advantages it will ultimately provide, his efforts will be wasted. I would save him that effort, especially given that the window of opportunity to do this is actually quite small. It was fully expected that GMP would temporarily have the jump on MPIR in a number of significant areas. Fully expected, and there were few surprises. The fact that they virtually threw everything they had at us, whether polished or not, was a surprise. One clear advantage of MPIR. It runs natively on Windows. Obviously that matters a lot to Sage. When and if GMP is prepared to deal with this, then David has the chance of making a case. Until then, there is no case. To take any other attitude is ignoring the elephant in the room. Virtually every contributor to MPIR has tried to get improvements accepted into GMP and failed. David Harvey managed it, but at the cost of signing over his copyright, having an organisation not directly involved in the project decide the license and having his code become so inextricably intertwined with that of TG's that he could not contribute it to both MPIR and GMP as he initially intended. Further, the GMP maintainer's attitude to native support for Windows is a matter of public record. The mandate for the MPIR fork of GMP is as strong as ever. It won't be going away, and I would save David from wasting his effort on trying to make it go away. I don't have any objections to making a GMP spkg, except the obvious. It is fundamentally wasted effort in comparison with just helping us improve MPIR. That said, if David wishes to provide support for GMP for Sage users, so long as he is prepared to do that work and not just expect someone else to do it, then +1 from me. It isn't my intention to alienate David, and never has been. Instead, I wish to prompt him to realise that Sage can gain a lot from the success of MPIR, both financially, in terms of platform support and ultimately I believe in terms of ultimate performance goals. I don't wish to appear to presume anything, but it is also my strong opinion that MPIR is a much more faithful representation of the Sage way of doing things than GMP is. If it isn't, help us to make it so by contributing. We currently have five people committed to making significant code improvements over the next year or so and the help of Mariah Lennox, Michael Abshoff, Jeff Gilchrist and from time to time, various others in relation to build and testing issues. We also have the prospect of some really significant funding for MPIR in the not too distant future and have been provided with significant resources for build testing of our code on hardware. But the project is not currently suffering from being over bloated. We can handle more contributors and look forward to them signing on. The more people that contribute, the quicker we will realise our goals. We already provide significant advantages over GMP in some areas and there is plenty more of that to come. People too easily forget that just one week ago, the tables were completely reversed. MPIR was *significantly* faster than GMP and still had all the other advantages over GMP such as native Windows support. All of a sudden, after two years, GMP does a release, and almost overnight David Harvey thinks it is reasonable to suggest that MPIR should be abandoned in favour of GMP. Come on, be reasonable! Bill. On 22 Apr, 07:58, Nick Alexander ncalexan...@gmail.com wrote: Seriously, it looks for all the world to me that you are intentionally trying to kick MPIR while it is down, knowing full well that a comparison is unfair at this point. I expect that by October/November this year we will match GMP feature for feature, and that will be regardless of whether another release is made. On top of that we'll have a whole load of new stuff GMP doesn't have. I promise you, we have some really, really nice stuff on the way, e.g. parallel code is one of the main new focuses, and development of that will start in about 4 weeks. Will you support us in October/November when there is a clear reason to do so? In the mean time, how about letting us get on with our work. Better still, how about contributing your improvements to *both* projects. Bill, David, We're all friends here. Let's not let this escalate. Nick --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel
[sage-devel] Re: GMP 4.3.0
Hi all, On 22 Apr., 06:45, William Stein wst...@gmail.com wrote: 2009/4/21 David Harvey dmhar...@cims.nyu.edu: On Apr 21, 2:31 pm, Bill Hart goodwillh...@googlemail.com wrote: In some cases it would be less work to just contribute features directly to MPIR to bring the current code up to par. I think you are underestimating how much work it is to design, write and debug these things. And whatever happened to not reinventing the wheel? I suppose that's a Sage motto but not an MPIR one? david The phrase is Building the car instead of reinventing the wheel. This was a description that an Italian Sage user used to describe the Sage project in its early days, when the only developers were me, David Joyner, and David Kohel. To me, the emphasis is on building the car, i.e., creating a viable alternative to the Ma*'s, instead of an emphasis on reinventing the wheel. Successful car manufacturers such as BMW, Toyota, etc., do not just take a bunch of off-the-shelf components and assemble a car. They innovate by creating better engines, carefully refining manufacturing processes, and constantly rethinking everything from external airflow to cupholder ergonomics. Also some doctests related to modular symbols. I don't know enough about this area to tell whether it's xgcd related or whether it's really a new bug in GMP. Those are all caused by xgcd returning a different choice of valid answer. The xgcd choice impacts the (highly noncanonical) choice of homology class representatives for modular symbols. I have on my to-do-list for a long time now the task to introduce canonical choices for e.g. P1List and for bases of modular symbol spaces. It would help a lot when interfacing with C libraries that do certain calculations very fast, e.g. the set of Heilbronn matrices for massive p Hecke operators. And there still seem to be certain 32bit versus 64bit issues open due to the use of hash() (e.g. for composite levels). So these specific differences can be hoped for to vanish sooner or later. This leaves the issue of checking that gmp works -- and in particular, the doctests getting different results with gmp vs. mpir. I don't think the doctesting issue is an insurmountable hurdle -- we already have a system set up to change doctests on 32 vs. 64 bit systems; it would take a little doing, but I don't see why we couldn't set something up to have # gmp and # mpir for certain results. It seems like both the gmp and mpir devs would get some use out of this -- both would be able to check that they return consistent results across all of the doctests in sage that use their code, which is a good thing. Plus, one would have a list of known places where gmp and mpir have different behavior -- again, good for both camps. (Especially when end-users switching from gmp to mpir or vice-versa get different results with their code, for instance.) Seems like a very complex solution for very little benefit. I do not think the above would be too difficult. I implemented a tagged optional doctesting system, which is already in Sage, which would _almost_ make doing the above reasonably easy. In particular, we would extend the system so the following works: sage: line of input output output gmp gives # optional - gmp If one does sage -t -optional=gmp devel/sage/sage then the sage test suite would be run, but the output in tests that have # optional-gmp would expect that output. This would be easy to implement. It would be useful in other contexts as well, e.g., having Macaulay2 installed changes some doctest output in some cases, which is annoying, but which this system would fix. Doing make check may set some optional flags per default, e.g., after checking whether M2, gmp, etc. are installed. Who is going to go to the trouble of implementing and maintaining this? You, of course. :-) Though I would add the above extension to sage -t, since that would be fairly easy for me to do. Cool. Where's the patch to review? Honestly, I believe that such an extension is an enhancement of the Sage doctesting system/environment being of some importance, independently of the GMP versus MPIR topic discussed here. Concerning the latter, IMHO the Gnome project wouldn't nearly be where and what it is without the KDE project. And today, both projects profit from each other's existence. Cheers, gsw -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: GMP 4.3.0
2009/4/22 Georg S. Weber georgswe...@googlemail.com: I have on my to-do-list for a long time now the task to introduce canonical choices for e.g. P1List and for bases of modular symbol spaces. It would help a lot when interfacing with C libraries that do certain calculations very fast, e.g. the set of Heilbronn matrices for massive p Hecke operators. And there still seem to be certain 32bit versus 64bit issues open due to the use of hash() (e.g. for composite levels). This (canonical choices for P1List) is something which interests me greatly, and I would be interested in continuing that discussion, but not in this thread (perhaps on sage-nt?) John Cheers, gsw -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: GMP 4.3.0
Oh look, I've been involved in Sage since mid-2006. This is the first major strategic decision with which I've disagreed so strongly, and the first time I've felt truly unwelcome on this list. It's quite depressing. I sincerely believe the costs of the fork to the community outweigh the benefits. Probably no-one will believe me, but this whole kerfuffle started as a result of me trying some shuttle diplomacy to get the two projects talking. The personal animosities involved are quite astonishing. Hopefully my planned career as a mathematician will be more successful than my career as a diplomat. Anyway, forget it. Good luck with MPIR guys. david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: GMP 4.3.0
2009/4/22 David Harvey dmhar...@cims.nyu.edu: Oh look, I've been involved in Sage since mid-2006. This is the first major strategic decision with which I've disagreed so strongly, and the first time I've felt truly unwelcome on this list. It's quite depressing. Of course you are not unwelcome on this list! John david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: GMP 4.3.0
On Wed, Apr 22, 2009 at 6:22 AM, David Harvey dmhar...@cims.nyu.edu wrote: Oh look, I've been involved in Sage since mid-2006. This is the first major strategic decision with which I've disagreed so strongly, and the first time I've felt truly unwelcome on this list. It's quite depressing. I sincerely believe the costs of the fork to the community outweigh the benefits. Probably no-one will believe me, but this whole kerfuffle started as a result of me trying some shuttle diplomacy to get the two projects talking. The personal animosities involved are quite astonishing. Hopefully my planned career as a mathematician will be more successful than my career as a diplomat. Anyway, forget it. Good luck with MPIR guys. david You are certainly not unwelcome! William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: GMP 4.3.0
On Tue, Apr 21, 2009 at 9:38 AM, dmharvey dmhar...@cims.nyu.edu wrote: Hi folks, I have made a basic spkg for GMP 4.3.0: http://sage.math.washington.edu/home/dmharvey/gmp-4.3.0.spkg I've only tested on a linux opteron system. It builds fine; there are various doctest failures that look related to non-canonical XGCD output. Quite possibly it won't yet even build on other sage-supported systems. Just one quick warning: If you try this on sage.math.washington.edu, it will appear to be substantially slower than the mpir included in vanilla sage-3.4.1, due to a bug in the GMP configuration script, which misdetect sage.math's Dunnington Xeon processors as Atom N270's (i.e., a netbook). Correctly configured, GMP is quite fast on sage.math. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: GMP 4.3.0
On Tue, Apr 21, 2009 at 9:38 AM, dmharvey dmhar...@cims.nyu.edu wrote:
Hi folks,
I have made a basic spkg for GMP 4.3.0:
http://sage.math.washington.edu/home/dmharvey/gmp-4.3.0.spkg
I've only tested on a linux opteron system. It builds fine; there are
various doctest failures that look related to non-canonical XGCD
output. Quite possibly it won't yet even build on other sage-supported
systems.
To try it out, you will need to remove SAGE_ROOT/spkg/standard/gmp-
mpir*.spkg and replace it with the above file, before starting the
build. (I'm not sure if you can install it into an existing sage
build.) You will also need to replace ecm-6.2.1.p0.spkg with
http://sage.math.washington.edu/home/dmharvey/ecm-6.2.2.spkg
(Note that this spkg has a hack in the configure script to make it not
get confused about different version numbers (4.3 vs 4.3.0) in
gmp.h and libgmp. Hopefully this will be unnecessary in the next
release of GMP-ECM.)
GMP 4.3.0 has a lot of nice speedups. One of my favourites is the
asymptotically improved XGCD implementation, for example (2.6 GHz
opteron):
== vanilla sage 3.4:
sage: p = 2^2976221 - 1 # nice big mersenne prime
sage: x = Integers(p).random_element()
sage: time y = 1/x
CPU times: user 43.19 s, sys: 0.02 s, total: 43.21 s
Wall time: 43.21 s
== Magma V2.15-1:
p := 2^2976221 - 1;
x := Integers(p) ! Random(p);
time y := 1/x;
Time: 3.590
== Mathematica 6.0:
In[1]:= p = 2^2976221 - 1;
In[2]:= x = RandomInteger[p];
In[3]:= Timing[y = PowerMod[x, -1, p];]
Out[3]= {2.02, Null}
== sage 3.4 with GMP 4.3.0:
sage: p = 2^2976221 - 1
sage: x = Integers(p).random_element()
sage: time y = 1/x
CPU times: user 1.45 s, sys: 0.01 s, total: 1.46 s
Wall time: 1.46 s
Recently Sage switched from GMP to the MPIR fork. I make no secret of
the fact that I disagree with this decision, although I did initially
support MPIR.
I just want to remind people that there is a lot more to take into
account when choosing
a library than just cherry picked benchmarks:
* a wide range of benchmarks
* support for an important range of platforms and operating systems
* the development process
* short and longterm goals
* talent of developers involved
* license
* copyright assignment requirements
* potential for financial support
-- William
I hope that Sage can figure out some way to incorporate
the improvements in GMP 4.3.0 (as competing systems like Mathematica,
Maple and Magma will soon surely do).
david
--
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
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: GMP 4.3.0
On Apr 21, 2009, at 9:50 AM, William Stein wrote: On Tue, Apr 21, 2009 at 9:38 AM, dmharvey dmhar...@cims.nyu.edu wrote: Hi folks, I have made a basic spkg for GMP 4.3.0: http://sage.math.washington.edu/home/dmharvey/gmp-4.3.0.spkg [...] Recently Sage switched from GMP to the MPIR fork. I make no secret of the fact that I disagree with this decision, although I did initially support MPIR. I just want to remind people that there is a lot more to take into account when choosing a library than just cherry picked benchmarks: * a wide range of benchmarks * support for an important range of platforms and operating systems * the development process * short and longterm goals * talent of developers involved * license * copyright assignment requirements * potential for financial support Of course neither GMP nor MPIR has the clear upper hand in all these criteria. I hope that Sage can figure out some way to incorporate the improvements in GMP 4.3.0 (as competing systems like Mathematica, Maple and Magma will soon surely do). I wish all forks could be as amicable as the Pyrex/Cython one, but understandably that is rarely the case. I support the reasons behind MPIR, but I think it's a very good thing to provide a GMP spkg for Sage--it gives users the choice. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: GMP 4.3.0
On Apr 21, 3:08 pm, Robert Bradshaw rober...@math.washington.edu wrote: I wish all forks could be as amicable as the Pyrex/Cython one, but understandably that is rarely the case. I support the reasons behind MPIR, but I think it's a very good thing to provide a GMP spkg for Sage--it gives users the choice. But Robert, that choice is illusory. Already it's impossible to install the gmp-4.3 spkg without breaking all those doctests. Over time, it's inevitable that the APIs of the two packages will diverge, unless the projects can come to some kind of agreement. I can't see how this can be a good thing. david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: GMP 4.3.0
On Apr 21, 2009, at 2:40 PM, David Harvey wrote: On Apr 21, 3:08 pm, Robert Bradshaw rober...@math.washington.edu wrote: I wish all forks could be as amicable as the Pyrex/Cython one, but understandably that is rarely the case. I support the reasons behind MPIR, but I think it's a very good thing to provide a GMP spkg for Sage--it gives users the choice. But Robert, that choice is illusory. Already it's impossible to install the gmp-4.3 spkg without breaking all those doctests. The only doctests that break are the xgcd ones, right? This has been an issue before, and so I think perhaps the doctests should be improved. Over time, it's inevitable that the APIs of the two packages will diverge, unless the projects can come to some kind of agreement. I can't see how this can be a good thing. You're right, I don't see this as a good long-term solution. I really hope the two projects can come to some kind of agreement--the current situation is in many ways a waste of time and recourses. Of course this may be wishful thinking given the clashing of goals, licensing issues, and personalities. However, the (upper level) gmp api is pretty stable as far as api's go, so I think it's good to have this option in the short term while the dust settles until a better relationship between the projects can be reached. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: GMP 4.3.0
I wish all forks could be as amicable as the Pyrex/Cython one, but understandably that is rarely the case. I support the reasons behind MPIR, but I think it's a very good thing to provide a GMP spkg for Sage--it gives users the choice. But Robert, that choice is illusory. Already it's impossible to install the gmp-4.3 spkg without breaking all those doctests. Over time, it's inevitable that the APIs of the two packages will diverge, unless the projects can come to some kind of agreement. I can't see how this can be a good thing. I also would like to see both a gmp and mpir spkg available. Even if someone never wanted to use gmp (for whatever reasons, be they licensing or other), I think it would be good to have both easily available -- for consistency checks, benchmarking, etc. Probably the vast majority of Sage users just want to use whatever is fastest for the problem on hand -- and as Robert pointed out, that probably varies from problem to problem ... It seems like having an optional gmp spkg that was intended for advanced users could be a reasonable goal. By advanced, all I really mean is that it won't be thoroughly tested as part of the release process, maybe just on sage.math and by interested parties -- much like the interfaces to Maple, Magma, and Mathematica, I think. There are definitely maintenance issues with trying to make gmp build correctly on all of the supported platforms for Sage, since gmp doesn't support all those OS/hardware configurations. The spkg-install could just spit an error and exit if the configuration isn't correct. I think this should be (1) not too hard to maintain, especially if we just use upstream gmp, and (2) very useful for some people (such as David). This should work until the two projects really start to diverge (in terms of API, etc), which may not happen for a while (if ever?). This leaves the issue of checking that gmp works -- and in particular, the doctests getting different results with gmp vs. mpir. I don't think the doctesting issue is an insurmountable hurdle -- we already have a system set up to change doctests on 32 vs. 64 bit systems; it would take a little doing, but I don't see why we couldn't set something up to have # gmp and # mpir for certain results. It seems like both the gmp and mpir devs would get some use out of this -- both would be able to check that they return consistent results across all of the doctests in sage that use their code, which is a good thing. Plus, one would have a list of known places where gmp and mpir have different behavior -- again, good for both camps. (Especially when end-users switching from gmp to mpir or vice-versa get different results with their code, for instance.) I just want to recognize an obvious objection to this: it could be hard to maintain this over the course of several years, especially if gmp and mpir really start to diverge. But at least for the parts of sage that use the common functionality (I don't see either of them *dropping* any of that functionality, no matter which direction the projects go), this seems workable for the short to medium term. -cc --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: GMP 4.3.0
On Apr 21, 2:31 pm, Bill Hart goodwillh...@googlemail.com wrote: In some cases it would be less work to just contribute features directly to MPIR to bring the current code up to par. I think you are underestimating how much work it is to design, write and debug these things. And whatever happened to not reinventing the wheel? I suppose that's a Sage motto but not an MPIR one? david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: GMP 4.3.0
On Apr 21, 8:06 pm, Robert Bradshaw rober...@math.washington.edu wrote: The only doctests that break are the xgcd ones, right? This has been an issue before, and so I think perhaps the doctests should be improved. Also some doctests related to modular symbols. I don't know enough about this area to tell whether it's xgcd related or whether it's really a new bug in GMP. Over time, it's inevitable that the APIs of the two packages will diverge, unless the projects can come to some kind of agreement. I can't see how this can be a good thing. You're right, I don't see this as a good long-term solution. I really hope the two projects can come to some kind of agreement--the current situation is in many ways a waste of time and recourses. Of course this may be wishful thinking given the clashing of goals, licensing issues, and personalities. However, the (upper level) gmp api is pretty stable as far as api's go, so I think it's good to have this option in the short term while the dust settles until a better relationship between the projects can be reached. I am talking about the mpn-level interface, which is relevant for a lot of the things I work on. david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: GMP 4.3.0
2009/4/21 David Harvey dmhar...@cims.nyu.edu: On Apr 21, 2:31 pm, Bill Hart goodwillh...@googlemail.com wrote: In some cases it would be less work to just contribute features directly to MPIR to bring the current code up to par. I think you are underestimating how much work it is to design, write and debug these things. And whatever happened to not reinventing the wheel? I suppose that's a Sage motto but not an MPIR one? david The phrase is Building the car instead of reinventing the wheel. This was a description that an Italian Sage user used to describe the Sage project in its early days, when the only developers were me, David Joyner, and David Kohel.To me, the emphasis is on building the car, i.e., creating a viable alternative to the Ma*'s, instead of an emphasis on reinventing the wheel. Successful car manufacturers such as BMW, Toyota, etc., do not just take a bunch of off-the-shelf components and assemble a car. They innovate by creating better engines, carefully refining manufacturing processes, and constantly rethinking everything from external airflow to cupholder ergonomics. Also some doctests related to modular symbols. I don't know enough about this area to tell whether it's xgcd related or whether it's really a new bug in GMP. Those are all caused by xgcd returning a different choice of valid answer. The xgcd choice impacts the (highly noncanonical) choice of homology class representatives for modular symbols. This leaves the issue of checking that gmp works -- and in particular, the doctests getting different results with gmp vs. mpir. I don't think the doctesting issue is an insurmountable hurdle -- we already have a system set up to change doctests on 32 vs. 64 bit systems; it would take a little doing, but I don't see why we couldn't set something up to have # gmp and # mpir for certain results. It seems like both the gmp and mpir devs would get some use out of this -- both would be able to check that they return consistent results across all of the doctests in sage that use their code, which is a good thing. Plus, one would have a list of known places where gmp and mpir have different behavior -- again, good for both camps. (Especially when end-users switching from gmp to mpir or vice-versa get different results with their code, for instance.) Seems like a very complex solution for very little benefit. I do not think the above would be too difficult. I implemented a tagged optional doctesting system, which is already in Sage, which would _almost_ make doing the above reasonably easy. In particular, we would extend the system so the following works: sage: line of input output output gmp gives # optional - gmp If one does sage -t -optional=gmp devel/sage/sage then the sage test suite would be run, but the output in tests that have # optional-gmp would expect that output. This would be easy to implement.It would be useful in other contexts as well, e.g., having Macaulay2 installed changes some doctest output in some cases, which is annoying, but which this system would fix. Doing make check may set some optional flags per default, e.g., after checking whether M2, gmp, etc. are installed. Who is going to go to the trouble of implementing and maintaining this? You, of course. :-)Though I would add the above extension to sage -t, since that would be fairly easy for me to do. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: GMP 4.3.0
On 21 Apr, 17:38, dmharvey dmhar...@cims.nyu.edu wrote: Recently Sage switched from GMP to the MPIR fork. I make no secret of the fact that I disagree with this decision, although I did initially support MPIR. I hope that Sage can figure out some way to incorporate the improvements in GMP 4.3.0 (as competing systems like Mathematica, Maple and Magma will soon surely do). It's not so easy for Mathematica. Brian Gladman will not be porting GMP 4.3.0 to Windows for them. He has made a very clear commitment to porting MPIR only. Bill. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: GMP 4.3.0
On 21 Apr, 22:40, David Harvey dmhar...@cims.nyu.edu wrote: SNIP Already it's impossible to install the gmp-4.3 spkg without breaking all those doctests. Over time, it's inevitable that the APIs of the two packages will diverge, unless the projects can come to some kind of agreement. I can't see how this can be a good thing. What kind of agreement did you have in mind? Bill. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
