Upgrade MPFR to 3.1.0 - Githubissues

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago

Our current MPFR spkg is fairly old (based on MPFR 2.4.2), and upgrading it to the latest [stable] upstream release is now on the high-priority wishlist.

Use http://perso.telecom-paristech.fr/~flori/sage/mpfr-3.1.0.p0.spkg

Apply:

Depends on #12171 Depends on #12548

Upstream: Fixed upstream, but not in a stable release.

CC: @jpflori @zimmermann6

Component: packages: standard

Keywords: sd36 sd32 MPFR spkg wishlist sd35.5

Author: Mike Hansen, Jean-Pierre Flori, Volker Braun

Reviewer: Paul Zimmermann, Jean-Pierre Flori, Volker Braun, Jeroen Demeyer

Merged: sage-5.0.beta7

Issue created by migration from https://trac.sagemath.org/ticket/11666

williamstein commented 13 years ago

Changed keywords from MPFR spkg wishlist to sd32 MPFR spkg wishlist

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago

Description changed:

--- 
+++ 
@@ -1,8 +1,38 @@
-Our current MPFR spkg is fairly old (based on MPFR 2.4.2), and upgrading it to the latest [stable] upstream release is now on the ["high-priority wishlist"](http://wiki.sagemath.org/days32/wishlist).
+Our current MPFR spkg is fairly old (based on **MPFR 2.4.2**), and upgrading it to the latest [stable] upstream release is now on the ["high-priority wishlist"](http://wiki.sagemath.org/days32/wishlist).

 `spkg-install` also needs a major rewrite, e.g. to make use of (some of) GMP's / MPIR's build flags.

-I think I'll provide a new spkg in the next days (weekend, say).
+*"I think I'll provide a new spkg in the next days (next weekend, say)."* [This unfortunately became a moving target; still on my high priority list though...]

-MPFR 3.0.1 was released on April 4th 2011; there are already some [additional upstream patches](http://www.mpfr.org/mpfr-current/allpatches) for that version; see http://www.mpfr.org/mpfr-current/ .
+---

+**MPFR 3.0.1** was released on April 4th 2011; there are already some [additional upstream patches](http://www.mpfr.org/mpfr-current/allpatches) for that version; see [http://www.mpfr.org/mpfr-current/](http://www.mpfr.org/mpfr-current/).
+
+---
+
+Yet **MPFR 3.1.0** is on the way, planned to be released September 30th (unless problems should occur).
+
+ == Changes from versions 3.0.* to version 3.1.0: ==
+
+- The MPFR source has been reorganized.
+- Dropped `ansi2knr` support.
+- TLS support is now detected automatically. If TLS is supported, MPFR is built as thread safe by default. To disable TLS explicitly, configure MPFR with `--disable-thread-safe`.
+- New `--enable-gmp-internals` `configure` option to use GMP's undocumented functions (not from the public API). Note that library versioning is not guaranteed to work if this option is used.
+- The `mpfr_urandom()` and `mpfr_urandomb()` functions now return identical values on processors with different word size (assuming the same random seed, and since the GMP random generator does not depend itself on the word size, cf. [http://gmplib.org/list-archives/gmp-devel/2010-September/001642.html](http://gmplib.org/list-archives/gmp-devel/2010-September/001642.html)).
+- The `mpfr_add_one_ulp()` and `mpfr_sub_one_ulp()` macros (which are obsolete and no more documented) will be removed in a future release.
+- Speed improvement for the `mpfr_sqr()` and `mpfr_div()` functions using Mulders' algorithm. As a consequence, other functions using those routines are also faster.
+- Much faster formatted output (`mpfr_printf()`, etc.) with `%Rg` and similar.
+- The `--with-gmp-build` `configure` option can now be used when the GMP source directory and the GMP build directory are different (without having to copy header files manually as before).
+- New functions `mpfr_buildopt_tune_case()`, `mpfr_frexp()`, `mpfr_grandom()` and `mpfr_z_sub()`.
+- New division-by-zero exception (flag) and associated functions.
+- The `mpfr.h` header can be included several times, while still supporting optional functions (see Section "Headers and Libraries" in the manual).
+- Updated tuning parameters.
+- Improved MPFR manual.
+- MPFR tests: `libtool` no longer generates wrapper scripts with `make check` (so that running the tests under `valgrind` or `gdb` is easier).
+- Bug fixes.
+
+   Note: The `mpfr_subnormalize()` implementation up to MPFR 3.0.0 did not change the flags. In particular, it did not follow the generic rule concerning the inexact flag (and no special behavior was specified). The case of the underflow flag was more a lack of specification.
+
+
+Tarballs of the current **release candidate** (rc1) are available in various formats (regarding the compression method); a bzipped one can be found [here](http://boxen.math.washington.edu/home/leif/Sage/spkgs/upstream/mpfr-3.1.0-rc1.tar.bz2) (`sage.math`) or [here](http://www.mpfr.org/mpfr-3.1.0/mpfr-3.1.0-rc1.tar.bz2) (upstream).
+

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago

comment:4

The second release candidate is out:

[...] The main changes since this first release candidate are:

Fixed --enable-gmp-internals.
Handle the special cases in mpfr_cmp_q() and mpfr_cmp_f() (fixing the problem with the erange flag in particular).
Added mpfr_buildopt_gmpinternals_p() function.
MPFR manual update and minor corrections.

Here's a second release candidate. As there should not be new platform-specific problems, the final release is delayed by a few days only.

[...]

http://www.mpfr.org/mpfr-3.1.0/mpfr-3.1.0-rc2.tar.bz2

[...]

The MD5's:

[...]

6ba48c87687959d5e68cd695686257f4 mpfr-3.1.0-rc2.tar.bz2

[...]

[...]

Final release now scheduled for October 3rd.

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago

Description changed:

--- 
+++ 
@@ -34,5 +34,5 @@
    Note: The `mpfr_subnormalize()` implementation up to MPFR 3.0.0 did not change the flags. In particular, it did not follow the generic rule concerning the inexact flag (and no special behavior was specified). The case of the underflow flag was more a lack of specification.

-Tarballs of the current **release candidate** (rc1) are available in various formats (regarding the compression method); a bzipped one can be found [here](http://boxen.math.washington.edu/home/leif/Sage/spkgs/upstream/mpfr-3.1.0-rc1.tar.bz2) (`sage.math`) or [here](http://www.mpfr.org/mpfr-3.1.0/mpfr-3.1.0-rc1.tar.bz2) (upstream).
+Tarballs of the current **release candidate** (rc2) are available in various formats (regarding the compression method); a bzipped one can be found [here](http://boxen.math.washington.edu/home/leif/Sage/spkgs/upstream/mpfr-3.1.0-rc2.tar.bz2) (`sage.math`) or [here](http://www.mpfr.org/mpfr-3.1.0/mpfr-3.1.0-rc2.tar.bz2) (upstream).

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago

Description changed:

--- 
+++ 
@@ -10,7 +10,7 @@

 ---

-Yet **MPFR 3.1.0** is on the way, planned to be released September 30th (unless problems should occur).
+**MPFR 3.1.0** [has been released October 3rd 2011](http://www.mpfr.org/mpfr-3.1.0/).

  == Changes from versions 3.0.* to version 3.1.0: ==

@@ -34,5 +34,5 @@
    Note: The `mpfr_subnormalize()` implementation up to MPFR 3.0.0 did not change the flags. In particular, it did not follow the generic rule concerning the inexact flag (and no special behavior was specified). The case of the underflow flag was more a lack of specification.

-Tarballs of the current **release candidate** (rc2) are available in various formats (regarding the compression method); a bzipped one can be found [here](http://boxen.math.washington.edu/home/leif/Sage/spkgs/upstream/mpfr-3.1.0-rc2.tar.bz2) (`sage.math`) or [here](http://www.mpfr.org/mpfr-3.1.0/mpfr-3.1.0-rc2.tar.bz2) (upstream).
+Tarballs are available in various formats (regarding the compression method); a bzipped one can be found [here](http://www.mpfr.org/mpfr-3.1.0/mpfr-3.1.0.tar.bz2) (upstream).

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago

comment:5

The final MPFR 3.1.0 has been released today.

See the description for links.

mwhansen commented 12 years ago

Dependencies: 12171

mwhansen commented 12 years ago

Author: Mike Hansen

mwhansen commented 12 years ago

comment:7

I have an spkg at http://sage.math.washington.edu/mpfr-3.1.0.spkg. This is needed for flint2.

kiwifb commented 12 years ago

comment:8

Shouldn't the dependency be the other way around? That is mpfi needs mpfr rather than mpfr needs mpfi? Have you tested this on a 32bit OS?

mwhansen commented 12 years ago

comment:9

This version of MPFI should work with both versions of MPFR. However, the old version of MPFI will not work with the new version of MPFI.

I haven't tested it on a 32bit OS. This was primarily just so we could build flint2 in Sage.

zimmermann6 commented 12 years ago

comment:11

I wonder why comment [comment:8] speaks about MPFI. Also, upstream (MPFR) we have seen several problems with the --enable-thread-safe option which is now enabled by default. Unless needed for Sage, my advice would be to configure MPFR with --disable-thread-safe.

Paul

zimmermann6 commented 12 years ago

comment:12

the url from comment [comment:7] does not work.

Paul

kiwifb commented 12 years ago

comment:13

Replying to @zimmermann6:

I wonder why comment [comment:8] speaks about MPFI. Also, upstream (MPFR) we have seen several problems with the --enable-thread-safe option which is now enabled by default. Unless needed for Sage, my advice would be to configure MPFR with --disable-thread-safe.

I spoke about mpfi because this ticket is marked as depending on #12171 which is upgrading mpfi. My understanding of the dependency field is that it means that you need #12171 for this ticket. This is silly and should be the other way around.

I think comment 9 has not been written with a clear mind.

I asked about test on 32bit machine because of this [ https://github.com/cschwan/sage-on-gentoo/issues/13].

mwhansen commented 12 years ago

comment:14

The spkg is actually at http://sage.math.washington.edu/home/mhansen/mpfr-3.1.0.spkg

Let me clarify the MPFI issue since I must have been too tired when I tried before. If we were to just install this version of MPFR, the current MPFI (1.3.4) will fail to build since it uses something which has been removed/moved in the new version of MPFR. If the new version of MPFI works with both the old and new versions of MPFR. So, if we want to actually include this package in Sage, we have to have the new version of MPFI in first. This is the reason I listed the MPFI ticket as a dependency of this one.

kiwifb commented 12 years ago

comment:15

You are making sense now. I indeed remember making a patch for mpfi-1.4 to build against mpfr-3.x in gentoo, it would apply to 1.3.4 as well I think. Anyway there are a number of things to fix as far as I can see because of the inclusion of these two.

jpflori commented 12 years ago

comment:16

Some thoughts about the spkg-install script:

It sets some CFLAGS and others itself, is it needed? does not mpfr look for the gmp header and pumps from there if possible? and should we take advantage of this (as in done for mpir where spkg-install look at what mpir chooses if CFLAGS et al. are empty)?
Is the patch for Solaris stuff still needed? (see #6453) -> at least the code in mpn_exp.c did not change in mpfr 3.1.0, so I guess it has to be included to support outdated Solaris systems where memset is buggy?
It always runs the test suite, whether SAGE_CHECK is set (then it is ran twice...) or not (then just once), is there still a good reason for doing so? It seems that such a behavior was also present in the MPIR spkg but was removed (see #9522 and !#8664)
make should be replaced by $MAKE in spkg-check

zimmermann6 commented 12 years ago

comment:17

It sets some CFLAGS and others itself, is it needed?

as a developer of MPFR I strongly recommend to let MPFR choose the same CC and CFLAGS as GMP (they are read in gmp.h). Since we do this for MPFR, this greatly improved the portability of MPFR on different platforms with different compilers, in particuler it solves the ABI=32 vs ABI=64 issues.

Is the patch for Solaris stuff still needed?

I guess yes, since this was a bug in the Solaris kernel.

Paul

zimmermann6 commented 12 years ago

comment:18

I've tested this spkg on top of #12171 on my 64-bit laptop (Core 2 Duo): all doctests pass.

Paul

kiwifb commented 12 years ago

comment:19

Replying to @zimmermann6:

I've tested this spkg on top of #12171 on my 64-bit laptop (Core 2 Duo): all doctests pass.

Yes 64bit is fine as far as I can tell. It's 32bit that's the trouble - both linux and OS X [10.5.8], don't know about other like solaris or cygwin.

zimmermann6 commented 12 years ago

Changed keywords from sd32 MPFR spkg wishlist to sd32 MPFR spkg wishlist sd35.5

zimmermann6 commented 12 years ago

Reviewer: Paul Zimmermann

zimmermann6 commented 12 years ago

Changed dependencies from 12171 to #12171

zimmermann6 commented 12 years ago

comment:21

on a 32-bit Pentium 4, after applying #12171 and importing this spkg, I get when I start Sage:

ImportError: /localdisk/tmp/sage-4.7.2/local/lib/libmpfi.so.0: undefined symbol: mpfr_add_d
Error importing ipy_profile_sage - perhaps you should run %upgrade?
WARNING: Loading of ipy_profile_sage failed.

Maybe I should first import this spkg then that of MPFI?

Paul

jpflori commented 12 years ago

comment:22

Still about the spkg itself:

Is there any reason to "unset RM"? it says it messes with libtool while running "make check". I do not see this restriction in the MPIR package, or the MPFI one e.g. Is this for a specific architecture? Is this really needed? I guess this is fixed by #3537
MAKE is set back to make before running "make install" (and then "make check" in the original package), any undocumented reason?

I'll test all of this on my system but if someone can point me to the relevant info, I'd be grateful, Google wans not that helpful.

jpflori commented 12 years ago

comment:23

I've put an updated package implementing my remarks, mainly using the mpir spkg-install file, I've also updated the description and license info.

It can be found at

http://perso.telecom-paristech.fr/sage/mpfr-3.1.0.spkg

It seems to do what it should, and uccessfully built and rand MPFR test suite on a "usual" intel 64 bit system, not any idea if I broke anything for more exotic architectures. Did not ran sage test suite either.

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 12 years ago

comment:24

Replying to @jpflori:

It can be found at

http://perso.telecom-paristech.fr/sage/mpfr-3.1.0.spkg

I do get a 301 to http://perso.telecom-paristech.fr/~sage/mpfr-3.1.0.spkg and that gives a 404.

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 12 years ago

comment:25

Replying to @jpflori:

Still about the spkg itself:

Is there any reason to "unset RM"? it says it messes with libtool while running "make check". I do not see this restriction in the MPIR package, or the MPFI one e.g. Is this for a specific architecture? Is this really needed? I guess this is fixed by #3537.

Unsetting RM is safe, but meanwhile a bit redundant. Newer autotools use $RM instead of rm -f (or $RM -f), so tend to fail if RM happens to be set to (just) rm.

MAKE is set back to make before running "make install" (and then "make check" in the original package), any undocumented reason?

I'm pretty sure that's a relict from when people didn't know how to properly disable parallel make. If in doubt, use $MAKE -j1 install etc.

jpflori commented 12 years ago

comment:26

Sorry, this should be http://perso.telecom-paristech.fr/~flori/sage/mpfr-3.1.0.spkg

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 12 years ago

comment:27

Replying to @zimmermann6:

Maybe I should first import this spkg then that of MPFI?

Since MPFI depends on MPFR (and MPIR), you have to rebuild MPFI after upgrading one of the latter.

If you have enough time (and/or the machine is fast enough), you can copy new/updated spkgs into $SAGE_ROOT/spkg/standard/ and run

$ env SAGE_UPGRADING=yes make build

afterwards. That way all dependent packages automatically get rebuilt, which can take some time.

(Unfortunately there are also a couple of stupid transitive dependencies; e.g. ATLAS gets rebuilt if you update readline -- just because ATLAS now has an spkg-install file written in Python, and Python depends on readline... So a lot of rebuilds performed by make aren't really necessary.)

zimmermann6 commented 12 years ago

Work Issues: fails on 32-bit

zimmermann6 commented 12 years ago

comment:28

I tried importing the MPFI spkg+patches (#12171) and that spkg on top of 4.8.alpha6 on a 32-bit Pentium 4 and got the following failures:

sage -t  "devel/sage-main/sage/matrix/matrix_mpolynomial_dense.pyx"
sage -t  "devel/sage-main/sage/matrix/constructor.py"
sage -t  "devel/sage-main/sage/matrix/matrix2.pyx"
sage -t  "devel/sage-main/sage/misc/randstate.pyx"
sage -t  "devel/sage-main/sage/modules/free_module_element.pyx"
sage -t  "devel/sage-main/sage/rings/real_mpfi.pyx"
sage -t  "devel/sage-main/sage/rings/complex_field.py"
sage -t  "devel/sage-main/sage/rings/complex_interval_field.py"
sage -t  "devel/sage-main/sage/rings/real_mpfr.pyx" # Killed/crashed
sage -t  "devel/sage-main/sage/schemes/elliptic_curves/ell_rational_field.py"

Paul

zimmermann6 commented 12 years ago

comment:29

the failures are most likely due to the fact that the mpfr_urandom and mpfr_urandomb return identical values on processors with different word size in MPFR 3.1.0 (see http://www.mpfr.org/mpfr-3.1.0/#changes).

The bad news is that this will need changing the doctests.

The good news is that we won't need any more different doctests on 32-bit and 64-bit (assuming the MPIR random generator is independent of the word size).

Paul Zimmermann

jpflori commented 12 years ago

comment:30

For the record, Mike's spkg and my updated one both need to be rebased on top of #12131.

I'll take care of that later.

jpflori commented 12 years ago

comment:31

You can finally find a rebased spkg where I discarded some stuff involving ABI which previously made sage print that it was building for 32 bits, whereas it actually had no effect, and which is rebased on #12131 at the usual address:

http://perso.telecom-paristech.fr/~flori/sage/mpfr-3.1.0.spkg

I guess the issue with doctests is the last step before "needs review"

jpflori commented 12 years ago

Description changed:

--- 
+++ 
@@ -1,38 +1,30 @@
-Our current MPFR spkg is fairly old (based on **MPFR 2.4.2**), and upgrading it to the latest [stable] upstream release is now on the ["high-priority wishlist"](http://wiki.sagemath.org/days32/wishlist).
+Our current MPFR spkg is fairly old (based on **MPFR 2.4.2**), and upgrading it to the latest [stable] upstream release is now on the [high-priority wishlist](http://wiki.sagemath.org/days32/wishlist).

-`spkg-install` also needs a major rewrite, e.g. to make use of (some of) GMP's / MPIR's build flags.
-
-*"I think I'll provide a new spkg in the next days (next weekend, say)."* [This unfortunately became a moving target; still on my high priority list though...]
+Use http://perso.telecom-paristech.fr/~flori/sage/mpfr-3.1.0.spkg

 ---
-
 **MPFR 3.0.1** was released on April 4th 2011; there are already some [additional upstream patches](http://www.mpfr.org/mpfr-current/allpatches) for that version; see [http://www.mpfr.org/mpfr-current/](http://www.mpfr.org/mpfr-current/).

 ---
-
 **MPFR 3.1.0** [has been released October 3rd 2011](http://www.mpfr.org/mpfr-3.1.0/).

- == Changes from versions 3.0.* to version 3.1.0: ==
-
-- The MPFR source has been reorganized.
-- Dropped `ansi2knr` support.
-- TLS support is now detected automatically. If TLS is supported, MPFR is built as thread safe by default. To disable TLS explicitly, configure MPFR with `--disable-thread-safe`.
-- New `--enable-gmp-internals` `configure` option to use GMP's undocumented functions (not from the public API). Note that library versioning is not guaranteed to work if this option is used.
-- The `mpfr_urandom()` and `mpfr_urandomb()` functions now return identical values on processors with different word size (assuming the same random seed, and since the GMP random generator does not depend itself on the word size, cf. [http://gmplib.org/list-archives/gmp-devel/2010-September/001642.html](http://gmplib.org/list-archives/gmp-devel/2010-September/001642.html)).
-- The `mpfr_add_one_ulp()` and `mpfr_sub_one_ulp()` macros (which are obsolete and no more documented) will be removed in a future release.
-- Speed improvement for the `mpfr_sqr()` and `mpfr_div()` functions using Mulders' algorithm. As a consequence, other functions using those routines are also faster.
-- Much faster formatted output (`mpfr_printf()`, etc.) with `%Rg` and similar.
-- The `--with-gmp-build` `configure` option can now be used when the GMP source directory and the GMP build directory are different (without having to copy header files manually as before).
-- New functions `mpfr_buildopt_tune_case()`, `mpfr_frexp()`, `mpfr_grandom()` and `mpfr_z_sub()`.
-- New division-by-zero exception (flag) and associated functions.
-- The `mpfr.h` header can be included several times, while still supporting optional functions (see Section "Headers and Libraries" in the manual).
-- Updated tuning parameters.
-- Improved MPFR manual.
-- MPFR tests: `libtool` no longer generates wrapper scripts with `make check` (so that running the tests under `valgrind` or `gdb` is easier).
-- Bug fixes.
-
-   Note: The `mpfr_subnormalize()` implementation up to MPFR 3.0.0 did not change the flags. In particular, it did not follow the generic rule concerning the inexact flag (and no special behavior was specified). The case of the underflow flag was more a lack of specification.
-
+## Changes from versions 3.0.* to version 3.1.0:
+* The MPFR source has been reorganized.
+* Dropped `ansi2knr` support.
+* TLS support is now detected automatically. If TLS is supported, MPFR is built as thread safe by default. To disable TLS explicitly, configure MPFR with `--disable-thread-safe`.
+* New `--enable-gmp-internals` `configure` option to use GMP's undocumented functions (not from the public API). Note that library versioning is not guaranteed to work if this option is used.
+* The `mpfr_urandom()` and `mpfr_urandomb()` functions now return identical values on processors with different word size (assuming the same random seed, and since the GMP random generator does not depend itself on the word size, cf. [http://gmplib.org/list-archives/gmp-devel/2010-September/001642.html](http://gmplib.org/list-archives/gmp-devel/2010-September/001642.html)).
+* The `mpfr_add_one_ulp()` and `mpfr_sub_one_ulp()` macros (which are obsolete and no more documented) will be removed in a future release.
+* Speed improvement for the `mpfr_sqr()` and `mpfr_div()` functions using Mulders' algorithm. As a consequence, other functions using those routines are also faster.
+* Much faster formatted output (`mpfr_printf()`, etc.) with `%Rg` and similar.
+* The `--with-gmp-build` `configure` option can now be used when the GMP source directory and the GMP build directory are different (without having to copy header files manually as before).
+* New functions `mpfr_buildopt_tune_case()`, `mpfr_frexp()`, `mpfr_grandom()` and `mpfr_z_sub()`.
+* New division-by-zero exception (flag) and associated functions.
+* The `mpfr.h` header can be included several times, while still supporting optional functions (see Section "Headers and Libraries" in the manual).
+* Updated tuning parameters.
+* Improved MPFR manual.
+* MPFR tests: `libtool` no longer generates wrapper scripts with `make check` (so that running the tests under `valgrind` or `gdb` is easier).
+* Bug fixes.
+ Note: The `mpfr_subnormalize()` implementation up to MPFR 3.0.0 did not change the flags. In particular, it did not follow the generic rule concerning the inexact flag (and no special behavior was specified). The case of the underflow flag was more a lack of specification.

 Tarballs are available in various formats (regarding the compression method); a bzipped one can be found [here](http://www.mpfr.org/mpfr-3.1.0/mpfr-3.1.0.tar.bz2) (upstream).
-

jpflori commented 12 years ago

Changed work issues from fails on 32-bit to failing doctests for 32 bits

jpflori commented 12 years ago

Changed author from Mike Hansen to Mike Hansen, Jean-Pierre Flori

jpflori commented 12 years ago

comment:32

I guess my last package should be rebased on #12366 which has been merged into 5.beta4.

Paul, any news on the doctests problems ?

zimmermann6 commented 12 years ago

comment:33

I will check the doctests on cicero (skynet) but I guess the issue is still there, since nothing was changed. I will try to make a patch (but since I'm in holidays, it might take some time).

Paul

zimmermann6 commented 12 years ago

comment:34

I tried this patch (with dependencies) on top of Sage 4.8 and got several doctests failures:

        sage -t  devel/sage-11666/sage/schemes/elliptic_curves/ell_rational_field.py # 2 doctests failed
        sage -t  devel/sage-11666/sage/schemes/elliptic_curves/heegner.py # 2 doctests failed
        sage -t  devel/sage-11666/sage/matrix/matrix2.pyx # 3 doctests failed
        sage -t  devel/sage-11666/sage/combinat/partition.py # 30 doctests failed
        sage -t  devel/sage-11666/sage/calculus/calculus.py # 7 doctests failed
        sage -t  devel/sage-11666/sage/misc/randstate.pyx # 13 doctests failed
        sage -t  devel/sage-11666/sage/misc/misc.py # 1 doctests failed
        sage -t  devel/sage-11666/sage/modules/free_module_element.pyx # 2 doctests failed
        sage -t  devel/sage-11666/sage/rings/real_mpfr.pyx # 12 doctests failed
        sage -t  devel/sage-11666/sage/matrix/constructor.py # 2 doctests failed
        sage -t  devel/sage-11666/sage/combinat/sloane_functions.py # 5 doctests failed
        sage -t  devel/sage-11666/sage/misc/cachefunc.py # 14 doctests failed
        sage -t  devel/sage-11666/sage/combinat/combinat.py # 1 doctests failed
        sage -t  devel/sage-11666/sage/libs/fplll/fplll.pyx # Killed/crashed
        sage -t  devel/sage-11666/sage/combinat/species/species.py # 3 doctests failed
        sage -t  devel/sage-11666/sage/combinat/species/sum_species.py # 3 doctests failed
        sage -t  devel/sage-11666/sage/combinat/species/permutation_species.py # 3 doctests failed
        sage -t  devel/sage-11666/sage/sets/disjoint_union_enumerated_sets.py # 8 doctests failed
        sage -t  devel/sage-11666/sage/matrix/matrix_mpolynomial_dense.pyx # 2 doctests failed
        sage -t  devel/sage-11666/sage/combinat/species/partition_species.py # 4 doctests failed
        sage -t  devel/sage-11666/sage/combinat/species/product_species.py # 2 doctests failed
        sage -t  devel/sage-11666/sage/rings/complex_field.py # 4 doctests failed
        sage -t  devel/sage-11666/sage/rings/complex_interval_field.py # 3 doctests failed
        sage -t  devel/sage-11666/sage/combinat/partitions.pyx # 1 doctests failed
        sage -t  devel/sage-11666/sage/rings/real_mpfi.pyx # 5 doctests failed

Can someone reproduce that?

Paul

jpflori commented 12 years ago

comment:35

I've begun the test suite. Here are my failures on a Debian amd64 experimental system (on intel core i7) :

The following tests failed:

    sage -t  -force_lib devel/sage/sage/modular/modsym/ambient.py # 0 doctests failed
    sage -t  -force_lib devel/sage/sage/modular/hecke/hecke_operator.py # 0 doctests failed
    sage -t  -force_lib devel/sage/sage/modular/hecke/ambient_module.py # 0 doctests failed
    sage -t  -force_lib devel/sage/sage/modules/free_module_element.pyx # 2 doctests failed
    sage -t  -force_lib devel/sage/sage/matrix/matrix_mpolynomial_dense.pyx # 2 doctests failed
    sage -t  -force_lib devel/sage/sage/matrix/constructor.py # 2 doctests failed
    sage -t  -force_lib devel/sage/sage/matrix/matrix2.pyx # 3 doctests failed
    sage -t  -force_lib devel/sage/sage/rings/real_mpfi.pyx # 5 doctests failed
    sage -t  -force_lib devel/sage/sage/rings/complex_field.py # 4 doctests failed
    sage -t  -force_lib devel/sage/sage/rings/real_mpfr.pyx # 12 doctests failed
    sage -t  -force_lib devel/sage/sage/rings/complex_interval_field.py # 3 doctests failed
    sage -t  -force_lib devel/sage/sage/tests/cmdline.py # 4 doctests failed
    sage -t  -force_lib devel/sage/sage/misc/randstate.pyx # 13 doctests failed
    sage -t  -force_lib devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py # 2 doctests failed

I'll have a look at them tomorrow.

Some of them at least are just changes in random output (e. g. real_mpfr and real_mpfi)

jpflori commented 12 years ago

comment:36

Some other look more problematic:

sage -t  -force_lib devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py
  ***   Warning: new stack size = 1003360 (0.957 Mbytes).
  ***   Warning: new stack size = 1003360 (0.957 Mbytes).
Saturation index bound = 265
WARNING: saturation at primes p > 97 will not be done;  
points may be unsaturated at primes between 97 and index bound
Failed to saturate MW basis at primes [ ]
Saturation index bound = 265
WARNING: saturation at primes p > 199 will not be done;  
points may be unsaturated at primes between 199 and index bound
Failed to saturate MW basis at primes [ ]
After 10 attempts at enlargement, giving up!
--points not proved 2-saturated,
2-saturation failed!
Failed to saturate MW basis at primes [ 2 ]
2 After 10 attempts at enlargement, giving up!
--points not proved 2-saturated,
2-saturation failed!
Failed to saturate MW basis at primes [ 2 ]

Maybe because I did not rebuild Pari spkg?

Apart from running sage -b I just forced rebuild of libfplll before the above make ptest (because of lack of time).

I'll properly rebuild everything tomorrow and rerun the testsuite.

jpflori commented 12 years ago

comment:37

Nevermind, the above is potentially just verbosity and not related to the actual errors

File "/home/jp/boulot/sage/sage-4.8/devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py", line 2921:
    sage: 2 * E.elliptic_exponential(z)
Expected:
    (2.04119347066305 - 1.10251372205166*I : 2.23105000976838 - 2.69795281735238*I : 1.00000000000000)
Got:
    (-1.52184235874404 - 0.0581413944316544*I : 0.948655866506124 - 0.0381469928565030*I : 1.00000000000000)
**********************************************************************
File "/home/jp/boulot/sage/sage-4.8/devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py", line 2923:
    sage: E.elliptic_exponential(2 * z)
Expected:
    (2.04119347066305 - 1.10251372205167*I : 2.23105000976839 - 2.69795281735236*I : 1.00000000000000)
Got:
    (-1.52184235874404 - 0.0581413944316562*I : 0.948655866506128 - 0.0381469928565034*I : 1.00000000000000)
**********************************************************************

And the line above defining z implies random so...

jpflori commented 12 years ago

comment:38

On a different system (Debian amd64 experimental on an intel QuadCore2) I get

The following tests failed:

    sage -t  -force_lib devel/sage/sage/modules/free_module_element.pyx # 2 doctests failed
    sage -t  -force_lib devel/sage/sage/rings/real_mpfi.pyx # 5 doctests failed
    sage -t  -force_lib devel/sage/sage/rings/real_mpfr.pyx # 12 doctests failed
    sage -t  -force_lib devel/sage/sage/rings/complex_interval_field.py # 3 doctests failed
    sage -t  -force_lib devel/sage/sage/rings/complex_field.py # 4 doctests failed
    sage -t  -force_lib devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py # 2 doctests failed
    sage -t  -force_lib devel/sage/sage/matrix/constructor.py # 2 doctests failed
    sage -t  -force_lib devel/sage/sage/matrix/matrix2.pyx # 3 doctests failed
    sage -t  -force_lib devel/sage/sage/matrix/matrix_mpolynomial_dense.pyx # 2 doctests failed
    sage -t  -force_lib devel/sage/sage/misc/randstate.pyx # 13 doctests failed
----------------------------------------------------------------------

This also is on top of 4.8, but I could not launch sage before also rebuilding MPIR which was not necessary on the other system.

jpflori commented 12 years ago

Changed work issues from failing doctests for 32 bits to correct doctests

jpflori commented 12 years ago

comment:39

Replying to @zimmermann6:

I tried importing the MPFI spkg+patches (#12171) and that spkg on top of 4.8.alpha6 on a 32-bit Pentium 4 and got the following failures: sage -t "devel/sage-main/sage/matrix/matrix_mpolynomial_dense.pyx" sage -t "devel/sage-main/sage/matrix/constructor.py" sage -t "devel/sage-main/sage/matrix/matrix2.pyx" sage -t "devel/sage-main/sage/misc/randstate.pyx" sage -t "devel/sage-main/sage/modules/free_module_element.pyx" sage -t "devel/sage-main/sage/rings/real_mpfi.pyx" sage -t "devel/sage-main/sage/rings/complex_field.py" sage -t "devel/sage-main/sage/rings/complex_interval_field.py" sage -t "devel/sage-main/sage/rings/real_mpfr.pyx" # Killed/crashed sage -t "devel/sage-main/sage/schemes/elliptic_curves/ell_rational_field.py" Paul

My last failures happen in the same files as what you posted some time ago and are always involving some random function.

As you posted later, this should be because MPFR changed its behavior.

I'll post a patch fixing the doctest, but cannot test it on a 32 bits computer (nor exotic architectures), so I'll leave that to someone else.

The question is whether this change of behavior is actually a problem ?

If someone saved old stuff with a given random seed, or something like that, its results will not be reproducible... I do not really feel concerned about that.

If someone could also test the spkg on sunos, solaris, apple or other exotic oses/cpus combinations, that would be more than welcome.

jpflori commented 12 years ago

comment:40

After rebuilding mpir and atlas (which was screwed) on my core i7 setup, here is what I get

----------------------------------------------------------------------
The temporary doctesting directory
   /home/jp/.sage/tmp/jp_x220-9822
was not removed: it is not empty, presumably because doctests
failed or doctesting was interrupted.

----------------------------------------------------------------------

The following tests failed:

    sage -t  -force_lib devel/sage/sage/modular/modsym/space.py # 0 doctests failed
    sage -t  -force_lib devel/sage/sage/modules/free_module_element.pyx # 2 doctests failed
    sage -t  -force_lib devel/sage/sage/matrix/matrix_mpolynomial_dense.pyx # 2 doctests failed
    sage -t  -force_lib devel/sage/sage/matrix/constructor.py # 2 doctests failed
    sage -t  -force_lib devel/sage/sage/matrix/matrix2.pyx # 3 doctests failed
    sage -t  -force_lib devel/sage/sage/rings/real_mpfi.pyx # 5 doctests failed
    sage -t  -force_lib devel/sage/sage/rings/complex_field.py # 4 doctests failed
    sage -t  -force_lib devel/sage/sage/rings/real_mpfr.pyx # 12 doctests failed
    sage -t  -force_lib devel/sage/sage/rings/complex_interval_field.py # 3 doctests failed
    sage -t  -force_lib devel/sage/sage/tests/cmdline.py # 4 doctests failed
    sage -t  -force_lib devel/sage/sage/misc/randstate.pyx # 13 doctests failed
    sage -t  -force_lib devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py # 2 doctests failed

I guess something went wrong with that installation because the failing doctest in cmdline.pyx really look strange.

zimmermann6 commented 12 years ago

comment:41

Replying to @nexttime:

If you have enough time (and/or the machine is fast enough), you can copy new/updated spkgs into $SAGE_ROOT/spkg/standard/ and run
$ env SAGE_UPGRADING=yes make build
afterwards. That way all dependent packages automatically get rebuilt, which can take some time.

should I rename new packages with the old name? Or keep the new name? For example Sage 4.8 contains mpfi-1.3.4-cvs20071125.p9.spkg. Should I put mpfi-1.5.1.spkg aside this one, or rename it?

Paul

zimmermann6 commented 12 years ago

comment:42

I just ran the doctests on cicero (skynet) with vanilla 4.8 and all of them pass.

Paul

sagemath / sage

Upgrade MPFR to 3.1.0 #11666