On Apr 21, 8:31 pm, Craig Citro <craigci...@gmail.com> wrote:
> 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 ... 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. > 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.) Seems like a very complex solution for very little benefit. Who is going to go to the trouble of implementing and maintaining this? 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 -~----------~----~----~----~------~----~------~--~---
