On Monday 09 May 2011 22:38:34 Bill Hart wrote: > There may be some clues as to why Sage hasn't updated MPIR in over a year, > here: > > http://trac.sagemath.org/sage_trac/ticket/8664
It seems like the only outstanding issue is that sage is after a CFLAGS which appends rather than replaces , as far as I know all packages replace , but they also want our optimized flags as well -march=corei7avx etc. We would have to call it something else like CFLAGS_APPEND and the other bit I'm not sure on is whether we should just stick it on the end of CFLAGS after configure has made it's choices , or stick it on the end before configure has made it's choices. I suppose another possibility is for sage to run mpir's configure first so it can compile all packages with a better CFLAGS. > > I've personally completely lost touch with what the long term goals of > Sage are these days. There was a time when it seemed to matter on a > daily basis what was happening with MPIR.... > > The best way to get MPIR updated in Sage would be to do it yourself. > But I think one could easily underestimate the logistical > difficulties. > > There are similar issues with many of the major C libraries. > > Last year sometime I got all enthused about putting together a unified > number theory library which would be a selection of related packages > (BLAS, MPIR, MPFR, MPC, M4RI, Pari, NTL, FLINT, etc) released on a > regular basis as a single block that was guaranteed to all build > together with a single invocation of make. You seem to have been > making statements along those lines yourself, Jason, with your script > to build all these packages to test MPIR against. > > For many reasons, I on the other hand, gave up after less than a day's > work. Many Sage devs have repeatedly rejected introducing that kind of > modularity in Sage. It's near impossible to get all these libraries to > build on Windows. Some are in C++ and others have woeful shortcomings. > I realised that the field itself is probably not on a solid > theoretical footing; most number theorists don't know, and don't care > what is required for a computation to be considered reliable. > Eventually I realised most of the people actually writing low level > stuff weren't even number theorists, but were computer scientists. And > the most pressing issue of all is that there is no identifiable career > advantage to me, a number theorist, working on something like this. > > Anyhow, for a lot of people, this unified package used to *be* Sage, > many people thinking of Sage as being a single monolithic "core". I > don't know if I'm suggesting that the best way to get this done would > be to go and work on Sage itself. If you are a pragmatist, maybe that > is what I am suggesting. But I have never personally been much of a > pragmatist myself. > > Bill. > > On 9 May 2011 19:15, jason <ja...@njkfrudils.plus.com> wrote: > > Hi > > > > I notice that sage appears to be still using MPIR-1.2.2 , MPIR-2.4 which > > will be out in about 3weeks has a lot of config changes, but I'm doing > > many more tests including app tests so I'm confident that it will be OK > > but they might want to be more conservative though so perhaps we should > > release a v2.3.2 , this is easy as the required fixes are trivial so > > testing can be done on just a few machines. > > > > Jason > > > > -- > > You received this message because you are subscribed to the Google Groups > > "mpir-devel" group. > > To post to this group, send email to mpir-devel@googlegroups.com. > > To unsubscribe from this group, send email to > > mpir-devel+unsubscr...@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
