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