>> 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 -~----------~----~----~----~------~----~------~--~---
