On Thu, Jun 3, 2010 at 10:20 AM, Bill Hart <[email protected]> wrote: > For any Sage people reading this thread: > > MPIR now uses the same XGCD normalisation as GMP 5.0.1. but *NOT* > previous versions (e.g. NOT GMP 5.0.0) and GMP 4.3.2. This is the > normalisation Pari requires to operate correctly. It is expected that > the XGCD normalisation is now fixed forever and will not change again > in MPIR (and if we understand correctly from the GMP list, not in GMP > either). > > If you find a counterexample to that, please report the inputs you > provide to the xgcd function and what GMP and MPIR return and we'll > fix it. (We aren't expecting any counterexamples, as we have test code > for this and have run hundreds of millions of XGCD's to check.) >
Excellent. We'll change our doctests to reflect this. Thanks. -- William > Bill. > > On 3 June 2010 18:11, Bill Hart <[email protected]> wrote: >> A little bit more detail on the MPIR in Sage thing: >> >> It looks like MPIR 2.1.0 is slated to be released in Sage 5.0. It's >> actually one of the main goals for that release. Woot!! >> >> http://trac.sagemath.org/sage_trac/milestone/sage-5.0 >> >> That's only two weeks away, and it takes nearly a week to do the >> release *after* all the patches are written. So we need to release a >> solid MPIR ASAP so they have time to fix the remaining issues in Sage. >> >> It looks like someone patched ECM in Sage already. But there are now >> Sage doctest failures. In all likelihood these are due to GCD >> normalisation, and will require the attention of the people involved >> with writing the Sage doctests. I think this will get dealt with when >> the Sage 5.0 release process starts. It's a one off job that the Sage >> guys know needs to be done now that the GCD normalisation has been >> changed back to the original. See the following for more details: >> >> http://trac.sagemath.org/sage_trac/ticket/8664 >> >> Note that MPIR 2.0.1. on that ticket is now meant to read 2.1.0. There >> will be no MPIR 2.0.1. >> >> Bill. >> >> On 3 June 2010 17:43, Bill Hart <[email protected]> wrote: >>> On 3 June 2010 15:00, Jason Moxham <[email protected]> wrote: >>>> On Thursday 03 June 2010 04:58:30 Jason Moxham wrote: >>>>> On Wednesday 02 June 2010 17:45:26 Jason Moxham wrote: >>>>> > Looks good , there are only 2 or 3 real errors >>>>> > >>>>> > your cleo and iras errors are because you need to get icc in your path >>>>> > , >>>>> > you will hit 1 real error then , but we can easily fix that. >>>>> >>>>> I fixed it by just deleting the assert , we very rarely have them in asm >>>>> anyway , and that fixed the problem until we hit the next little error >>>>> >>>>> >>>>> ../.libs/libmpir.so -Wl,--rpath -Wl,/usr/local/lib >>>>> icc: command line remark #10010: option '-c99' is deprecated and will be >>>>> removed in a future release. See '-help deprecated' >>>>> icc: command line remark #10010: option '-c99' is deprecated and will be >>>>> removed in a future release. See '-help deprecated' >>>>> /home/jasonmoxham/sourcecode/mpir-2.1.0/cleo/.libs/libmpir.so: undefined >>>>> reference to `__gmpn_invert_limb' >>>>> icc -c99 -o .libs/t-bswap t-bswap.o ./.libs/libtests.a >>>>> /home/jasonmoxham/sourcecode/mpir-2.1.0/cleo/.libs/libmpir.so >>>>> ../.libs/libmpir.so -Wl,--rpath -Wl,/usr/local/lib >>>>> make[4]: *** [t-count_zeros] Error 1 >>>>> make[4]: *** Waiting for unfinished jobs.... >>>>> icc: command line remark #10010: option '-c99' is deprecated and will be >>>>> removed in a future release. See '-help deprecated' >>>>> t-constants.o: In function `main': >>>>> /home/jasonmoxham/sourcecode/mpir-2.1.0/./tests/t-constants.c:(.text+0x4b2) >>>>>: undefined reference to `__gmpn_invert_limb' >>>>> /home/jasonmoxham/sourcecode/mpir-2.1.0/cleo/.libs/libmpir.so: undefined >>>>> reference to `__gmpn_invert_limb' >>>>> make[4]: *** [t-constants] Error 1 >>>>> make[4]: *** [t-gmpmax] Error 1 >>>>> /home/jasonmoxham/sourcecode/mpir-2.1.0/cleo/.libs/libmpir.so: undefined >>>>> reference to `__gmpn_invert_limb' >>>>> make[4]: *** [t-bswap] Error 1 >>>>> make[4]: Leaving directory >>>>> `/home/jasonmoxham/sourcecode/mpir-2.1.0/cleo/tests' >>>>> make[3]: *** [check-am] Error 2 >>>>> make[3]: Leaving directory >>>>> `/home/jasonmoxham/sourcecode/mpir-2.1.0/cleo/tests' >>>>> make[2]: *** [check-recursive] Error 1 >>>>> make[2]: Leaving directory >>>>> `/home/jasonmoxham/sourcecode/mpir-2.1.0/cleo/tests' >>>>> make[1]: *** [check-recursive] Error 1 >>>>> make[1]: Leaving directory `/home/jasonmoxham/sourcecode/mpir-2.1.0/cleo' >>>>> make: *** [check] Error 2 >>>>> cleo >>>>> >>>>> PASSED CC=gcc CXX=g++ configure= >>>>> PASSED CC=gcc CXX=g++ configure= --enable-cxx --enable-gmpcompat >>>>> PASSED CC=gcc CXX=g++ configure= --enable-cxx --enable-gmpcompat --enable- >>>>> assert --enable-alloca=debug >>>>> PASSED CC=gcc CXX=g++ configure= --enable-cxx --enable-gmpcompat --enable- >>>>> assert --enable-alloca=debug --build=none-unknown-linux-gnu >>>>> PASSED CC=cc CXX=c++ configure= >>>>> PASSED CC=cc CXX=c++ configure= --enable-cxx --enable-gmpcompat >>>>> PASSED CC=cc CXX=c++ configure= --enable-cxx --enable-gmpcompat >>>>> --enable-assert --enable-alloca=debug >>>>> PASSED CC=cc CXX=c++ configure= --enable-cxx --enable-gmpcompat >>>>> --enable-assert --enable-alloca=debug --build=none-unknown-linux-gnu >>>>> PASSED CC=icc CXX=g++ configure= >>>>> PASSED CC=icc CXX=g++ configure= --enable-cxx --enable-gmpcompat >>>>> PASSED CC=icc CXX=g++ configure= --enable-cxx --enable-gmpcompat --enable- >>>>> assert --enable-alloca=debug >>>>> FAILED CC=icc CXX=g++ configure= --enable-cxx --enable-gmpcompat --enable- >>>>> assert --enable-alloca=debug --build=none-unknown-linux-gnu >>>>> >>>>> This looks easy to fix , I'll do it tomorrow >>>>> Jason >>>> >>>> This is caused by LONGLONG_STANDALONE not being defined ANYWHERE???? which >>>> makes invert_limb depend on udiv_qrnnd_preinv which depends on invert_limb >>>> which depends on ..... >>> >>> LONGLONG_STANDALONE shouldn't be defined anywhere. The longlong.h file >>> used to be maintained as a standalone file, but has not been for many >>> years. This define is left over from the days when it used to be used >>> that way. >>> >>>> >>>> As this is just to run some more tests and not a production mpir lib , I >>>> suggest we forget about it for now (plus it's only on icc not gcc) >>>> >>>> I've run the full mpirtests on my K8 and atom both with 64 and 32bit OSes >>>> as >>>> described before with no errors , and also on mark.skynet (although the >>>> test >>>> script burped at the end , but as the run took a full day , I debug the >>>> test >>>> script later) >>>> >>>> Are there any outstanding tests? >>>> I assume building sage with it went OK? >>> >>> The last I heard about sage was the ecm issue. I don't know if they've >>> updated ECM yet or not. It's not an upstream issue, as ECM have fixed >>> this in a more recent release. >>> >>>> >>>> Jason >>>> >>>> >>>> >>>>> >>>>> > for lena and flavius gcc34 doesn't have a g++ >>>>> > >>>>> > gcc54 has a broken c++ >>>>> > >>>>> > gcc42 has a broken c++ and there is no way to get a timer for tuning >>>>> > (same for cato) >>>>> > >>>>> > fulvia gcc4.5.0 is not installed right >>>>> > >>>>> > fulvia cc , 1 real error , suns assembler is old , we should force it to >>>>> > use yasm is all cases , I see if I can do it (I have to remove my brain >>>>> > first , to get in the autotools mood) , but it may have to wait for next >>>>> > release. >>>>> > >>>>> > bsd.math we dont support fat builds on a mac (PIC code is different) >>>>> > and >>>>> > they arn't needed that much >>>>> > >>>>> > gcc101 is a bsd system and I think we dont support fat builds (same as >>>>> > above?) so possibly a real error >>>>> > >>>>> > rest of the machines use gcc-4.3.2 which is broken >>>>> > >>>>> > I have updated the test script to reflect some of changes , but there >>>>> > are >>>>> > a lot of broken systems , so we will still get some errors from these. >>>>> > >>>>> > Jason >>>>> > >>>>> > On Wednesday 02 June 2010 16:47:22 Minh Nguyen wrote: >>>>> > > Hi folks, >>>>> > > >>>>> > > Build and test results for MPIR 2.1.0-rc2 on the build farm are >>>>> > > available at >>>>> > > >>>>> > > http://wiki.sagemath.org/mpir/BuildFarm/mpir-2.1.0#MPIR2.1.0-rc2 >>>>> > > >>>>> > > Each build was done using one thread, i.e. first exporting >>>>> > > >>>>> > > $ export MAKE='make' >>>>> > > >>>>> > > The test suite was ran using one CPU. On some machines, doing a >>>>> > > parallel build would result in a failure to tune, i.e. doing >>>>> > > >>>>> > > $ make tune >>>>> > > >>>>> > > after a parallel build would fail. So for each reported machine, I >>>>> > > only used one thread/CPU for build, check, tune, and test suite. >>>>> > > >>>>> > > -- >>>>> > > Regards >>>>> > > Minh Van Nguyen >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "mpir-devel" group. >>>> To post to this group, send email to [email protected]. >>>> To unsubscribe from this group, send email to >>>> [email protected]. >>>> 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/mpir-devel?hl=en. > > -- William Stein Professor of Mathematics University of Washington http://wstein.org -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
