On Jan 28, 7:03 pm, Robert Bradshaw <rober...@math.washington.edu> wrote: > On Jan 28, 2010, at 10:15 AM, William Stein wrote: > > > > > > > On Thu, Jan 28, 2010 at 10:02 AM, Bill Hart <goodwillh...@googlemail.com > > > wrote: > >> Hi all, > > >> it is with pleasure that we (finally) officially release MPIR 1.3.0. > >> It is available at our websitehttp://www.mpir.org/ > > >> Please note the following important things: > > >> * I have been unable to get any tests to pass on ultrasparc2 > >> machines, > >> including t2 (solaris) and gcc54 (linux). I am confident there are > >> not > >> bugs in the ultrasparc assembly code (as we haven't changed it and it > >> worked before). Thus if someone can tell me how to get MPIR to behave > >> on these machines "out-of-the-box" I will make the necessary changes > >> to MPIR. In the mean time, we have to officially consider MPIR broken > >> on such machines (or the machines we test on to be broken). Note this > >> is *not* a Solaris issue as MPIR builds just fine on Solaris. > > > Hmmm. That doesn't sound good. In order not to annoy David Kirkby > > off again, I guess this means we can't upgrade MPIR to version 1.3.0 > > in Sage? We could at least make it an optional package. > > I agree, though I hope the wait will be short. What has changed on t2 > in the meantime? > > >> * It is no longer necessary to issue make install gmp-compat, however > >> it is still necessary to use --enable-gmpcompat with configure if you > >> want a gmp.h and libgmp > > >> * Many users believe that mpz_nextprime returns a prime. In fact it > >> is > >> only guaranteed to define a number which is with high probability > >> prime. For this reason the function has been deprecated. Please use > >> the new mpz_next_likely_prime in its place. > > Isn't "probable prime" more standard terminology?
No, that has a specific mathematical meaning. MPIR does not compute a probable prime. > > > > > > >> * Most of the random functions in MPIR which require global random > >> state have been deprecated and new functions provided which have > >> local > >> state. This allows code using MPIR random functions to be threadsafe. > > >> * The functions mpz_div_2exp and mpz_div_ui have been removed from > >> MPIR. These were deprecated many years ago, but many people have > >> continued to use them. > > >> A quick workaround is to use the following defines: > > >> #ifndef mpz_div_2exp > >> #define mpz_div_2exp mpz_tdiv_q_2exp > >> #endif > > >> #ifndef mpz_div_ui > >> #define mpz_div_ui mpz_tdiv_q_ui > >> #endif > > >> However, the better fix is to actually replace all occurrences in > >> code. (Users of FLINT will have to wait a couple of days until I > >> issue > >> an update to FLINT, in particular the quadratic sieve, which still > >> uses the old functions - in the mean time, just add the above defines > >> to flint.h). > > > Does the above mean that you have decided to just deprecate any > > attempt at cross-compatibility with GMP? That's how my fuzzy "user > > ears" see this. > > Perhaps when configured with --enable-gmpcompat, it could include > these (and any other similar) defines in gmp.h. That has been suggested, but we decided that it was an incorrect approach. The functions have been deprecated in GMP too, for a very long time. We are all just being slack if we keep using them in our code. I will be fixing FLINT. Bill. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
