Sage: Ticket #11666: Upgrade MPFR to 3.1.0
https://trac.sagemath.org/ticket/11666
<p>
Our current MPFR spkg is fairly old (based on <strong>MPFR 2.4.2</strong>), and upgrading it to the latest [stable] upstream release is now on the <a class="ext-link" href="http://wiki.sagemath.org/days32/wishlist"><span class="icon"></span>high-priority wishlist</a>.
</p>
<p>
Use <a class="ext-link" href="http://perso.telecom-paristech.fr/~flori/sage/mpfr-3.1.0.spkg"><span class="icon"></span>http://perso.telecom-paristech.fr/~flori/sage/mpfr-3.1.0.spkg</a>
</p>
<p>
Apply:
</p>
<ul><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/11666/trac_11666_remove_random_hack.patch" title="Attachment 'trac_11666_remove_random_hack.patch' in Ticket #11666">trac_11666_remove_random_hack.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/11666/trac_11666_remove_random_hack.patch" title="Download"></a>
</li><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/11666/trac_11666_reduce_precision_max.patch" title="Attachment 'trac_11666_reduce_precision_max.patch' in Ticket #11666">trac_11666_reduce_precision_max.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/11666/trac_11666_reduce_precision_max.patch" title="Download"></a>
</li><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/11666/trac_11666_fix_random_doctests.patch" title="Attachment 'trac_11666_fix_random_doctests.patch' in Ticket #11666">trac_11666_fix_random_doctests.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/11666/trac_11666_fix_random_doctests.patch" title="Download"></a>
</li></ul>en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/11666
Trac 1.1.6wasWed, 24 Aug 2011 23:36:11 GMTkeywords changed
https://trac.sagemath.org/ticket/11666#comment:1
https://trac.sagemath.org/ticket/11666#comment:1
<ul>
<li><strong>keywords</strong>
<em>sd32</em> added
</li>
</ul>
TicketjpfloriFri, 16 Sep 2011 07:57:34 GMTcc set
https://trac.sagemath.org/ticket/11666#comment:2
https://trac.sagemath.org/ticket/11666#comment:2
<ul>
<li><strong>cc</strong>
<em>jpflori</em> added
</li>
</ul>
TicketleifSun, 18 Sep 2011 01:47:31 GMTowner, description, summary changed
https://trac.sagemath.org/ticket/11666#comment:3
https://trac.sagemath.org/ticket/11666#comment:3
<ul>
<li><strong>owner</strong>
changed from <em>tbd</em> to <em>leif</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/11666?action=diff&version=3">diff</a>)
</li>
<li><strong>summary</strong>
changed from <em>Upgrade MPFR to 3.0.1 + upstream patches</em> to <em>Upgrade MPFR to 3.0.1 + upstream patches or later (3.1.0)</em>
</li>
</ul>
TicketleifThu, 22 Sep 2011 17:07:45 GMTdescription changed
https://trac.sagemath.org/ticket/11666#comment:4
https://trac.sagemath.org/ticket/11666#comment:4
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/11666?action=diff&version=4">diff</a>)
</li>
</ul>
<p>
The second release candidate is out:
</p>
<blockquote>
<p>
[...] The main changes since this first release candidate are:
</p>
</blockquote>
<p>
</p>
<ul><li>Fixed <code>--enable-gmp-internals</code>.
</li><li>Handle the special cases in <code>mpfr_cmp_q()</code> and <code>mpfr_cmp_f()</code> (fixing the problem with the <code>erange</code> flag in particular).
</li><li>Added <code>mpfr_buildopt_gmpinternals_p()</code> function.
</li><li>MPFR manual update and minor corrections.
</li></ul><blockquote>
<p>
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.
</p>
</blockquote>
<blockquote>
<p>
[...] <br />
<a class="ext-link" href="http://www.mpfr.org/mpfr-3.1.0/mpfr-3.1.0-rc2.tar.bz2"><span class="icon"></span>http://www.mpfr.org/mpfr-3.1.0/mpfr-3.1.0-rc2.tar.bz2</a> <br />
[...] <br />
</p>
</blockquote>
<blockquote>
<p>
The MD5's: <br />
[...] <br />
<code>6ba48c87687959d5e68cd695686257f4 mpfr-3.1.0-rc2.tar.bz2</code> <br />
[...] <br />
</p>
</blockquote>
<blockquote>
<p>
[...]
</p>
</blockquote>
<p>
Final release now scheduled for October 3rd.
</p>
TicketleifMon, 03 Oct 2011 22:05:52 GMTdescription changed
https://trac.sagemath.org/ticket/11666#comment:5
https://trac.sagemath.org/ticket/11666#comment:5
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/11666?action=diff&version=5">diff</a>)
</li>
</ul>
<p>
The final MPFR 3.1.0 has been released today.
</p>
<p>
See the description for links.
</p>
TicketmhansenSat, 17 Dec 2011 10:53:53 GMTsummary changed; dependencies, author set
https://trac.sagemath.org/ticket/11666#comment:6
https://trac.sagemath.org/ticket/11666#comment:6
<ul>
<li><strong>summary</strong>
changed from <em>Upgrade MPFR to 3.0.1 + upstream patches or later (3.1.0)</em> to <em>Upgrade MPFR to 3.1.0</em>
</li>
<li><strong>dependencies</strong>
set to <em>12171</em>
</li>
<li><strong>author</strong>
set to <em>Mike Hansen</em>
</li>
</ul>
TicketmhansenSat, 17 Dec 2011 11:02:17 GMTstatus changed
https://trac.sagemath.org/ticket/11666#comment:7
https://trac.sagemath.org/ticket/11666#comment:7
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
</ul>
<p>
I have an spkg at <a class="ext-link" href="http://sage.math.washington.edu/mpfr-3.1.0.spkg"><span class="icon"></span>http://sage.math.washington.edu/mpfr-3.1.0.spkg</a>. This is needed for flint2.
</p>
TicketfbisseySat, 17 Dec 2011 18:55:14 GMT
https://trac.sagemath.org/ticket/11666#comment:8
https://trac.sagemath.org/ticket/11666#comment:8
<p>
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?
</p>
TicketmhansenSat, 17 Dec 2011 18:59:55 GMT
https://trac.sagemath.org/ticket/11666#comment:9
https://trac.sagemath.org/ticket/11666#comment:9
<p>
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.
</p>
<p>
I haven't tested it on a 32bit OS. This was primarily just so we could build flint2 in Sage.
</p>
TicketzimmermaSun, 18 Dec 2011 12:08:26 GMTcc changed
https://trac.sagemath.org/ticket/11666#comment:10
https://trac.sagemath.org/ticket/11666#comment:10
<ul>
<li><strong>cc</strong>
<em>zimmerma</em> added
</li>
</ul>
TicketzimmermaSun, 18 Dec 2011 19:25:24 GMT
https://trac.sagemath.org/ticket/11666#comment:11
https://trac.sagemath.org/ticket/11666#comment:11
<p>
I wonder why comment <a class="ticket" href="https://trac.sagemath.org/ticket/11666#comment:8" title="Comment 8">8</a> speaks about MPFI. Also, upstream (MPFR) we have seen several
problems with the <code>--enable-thread-safe</code> option which is now enabled by default. Unless needed
for Sage, my advice would be to configure MPFR with <code>--disable-thread-safe</code>.
</p>
<p>
Paul
</p>
TicketzimmermaSun, 18 Dec 2011 19:26:22 GMTstatus changed
https://trac.sagemath.org/ticket/11666#comment:12
https://trac.sagemath.org/ticket/11666#comment:12
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_info</em>
</li>
</ul>
<p>
the url from comment <a class="ticket" href="https://trac.sagemath.org/ticket/11666#comment:7" title="Comment 7">7</a> does not work.
</p>
<p>
Paul
</p>
TicketfbisseySun, 18 Dec 2011 21:05:57 GMT
https://trac.sagemath.org/ticket/11666#comment:13
https://trac.sagemath.org/ticket/11666#comment:13
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11666#comment:11" title="Comment 11">zimmerma</a>:
</p>
<blockquote class="citation">
<p>
I wonder why comment <a class="ticket" href="https://trac.sagemath.org/ticket/11666#comment:8" title="Comment 8">8</a> speaks about MPFI. Also, upstream (MPFR) we have seen several
problems with the <code>--enable-thread-safe</code> option which is now enabled by default. Unless needed
for Sage, my advice would be to configure MPFR with <code>--disable-thread-safe</code>.
</p>
</blockquote>
<p>
I spoke about mpfi because this ticket is marked as depending on <a class="closed ticket" href="https://trac.sagemath.org/ticket/12171" title="enhancement: Update MPFI to 1.5.1 (closed: fixed)">#12171</a> which is upgrading mpfi. My understanding of the dependency field is that it means that you need <a class="closed ticket" href="https://trac.sagemath.org/ticket/12171" title="enhancement: Update MPFI to 1.5.1 (closed: fixed)">#12171</a> for this ticket. This is silly and should be the other way around.
</p>
<p>
I think comment 9 has not been written with a clear mind.
</p>
<p>
I asked about test on 32bit machine because of this [ <a class="ext-link" href="https://github.com/cschwan/sage-on-gentoo/issues/13"><span class="icon"></span>https://github.com/cschwan/sage-on-gentoo/issues/13</a>].
</p>
TicketmhansenMon, 19 Dec 2011 10:56:51 GMT
https://trac.sagemath.org/ticket/11666#comment:14
https://trac.sagemath.org/ticket/11666#comment:14
<p>
The spkg is actually at <a class="ext-link" href="http://sage.math.washington.edu/home/mhansen/mpfr-3.1.0.spkg"><span class="icon"></span>http://sage.math.washington.edu/home/mhansen/mpfr-3.1.0.spkg</a>
</p>
<p>
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.
</p>
TicketfbisseyMon, 19 Dec 2011 18:21:08 GMT
https://trac.sagemath.org/ticket/11666#comment:15
https://trac.sagemath.org/ticket/11666#comment:15
<p>
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.
</p>
TicketjpfloriSun, 08 Jan 2012 12:28:00 GMT
https://trac.sagemath.org/ticket/11666#comment:16
https://trac.sagemath.org/ticket/11666#comment:16
<p>
Some thoughts about the spkg-install script:
</p>
<ul><li>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)?
</li><li>Is the patch for Solaris stuff still needed? (see <a class="closed ticket" href="https://trac.sagemath.org/ticket/6453" title="defect: [with spkg, positive review] MPFR test failures on Solaris 10 update 4 ... (closed: fixed)">#6453</a>) -> 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?
</li><li>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 <a class="closed ticket" href="https://trac.sagemath.org/ticket/9522" title="defect: MPIR: Don't check SAGE_CHECK in spkg-install (closed: fixed)">#9522</a> and #8664)
</li><li>make should be replaced by $MAKE in spkg-check
</li></ul>
TicketzimmermaSun, 08 Jan 2012 21:08:38 GMT
https://trac.sagemath.org/ticket/11666#comment:17
https://trac.sagemath.org/ticket/11666#comment:17
<blockquote class="citation">
<p>
It sets some CFLAGS and others itself, is it needed?
</p>
</blockquote>
<p>
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.
</p>
<blockquote class="citation">
<p>
Is the patch for Solaris stuff still needed?
</p>
</blockquote>
<p>
I guess yes, since this was a bug in the Solaris kernel.
</p>
<p>
Paul
</p>
TicketzimmermaSun, 08 Jan 2012 23:01:31 GMT
https://trac.sagemath.org/ticket/11666#comment:18
https://trac.sagemath.org/ticket/11666#comment:18
<p>
I've tested this spkg on top of <a class="closed ticket" href="https://trac.sagemath.org/ticket/12171" title="enhancement: Update MPFI to 1.5.1 (closed: fixed)">#12171</a> on my 64-bit laptop (Core 2 Duo): all doctests pass.
</p>
<p>
Paul
</p>
TicketfbisseyMon, 09 Jan 2012 00:35:02 GMT
https://trac.sagemath.org/ticket/11666#comment:19
https://trac.sagemath.org/ticket/11666#comment:19
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11666#comment:18" title="Comment 18">zimmerma</a>:
</p>
<blockquote class="citation">
<p>
I've tested this spkg on top of <a class="closed ticket" href="https://trac.sagemath.org/ticket/12171" title="enhancement: Update MPFI to 1.5.1 (closed: fixed)">#12171</a> on my 64-bit laptop (Core 2 Duo): all doctests pass.
</p>
</blockquote>
<p>
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.
</p>
TicketzimmermaMon, 09 Jan 2012 08:06:04 GMTkeywords changed
https://trac.sagemath.org/ticket/11666#comment:20
https://trac.sagemath.org/ticket/11666#comment:20
<ul>
<li><strong>keywords</strong>
<em>sd35.5</em> added
</li>
</ul>
TicketzimmermaMon, 09 Jan 2012 08:12:31 GMTdependencies changed; reviewer set
https://trac.sagemath.org/ticket/11666#comment:21
https://trac.sagemath.org/ticket/11666#comment:21
<ul>
<li><strong>reviewer</strong>
set to <em>Paul Zimmermann</em>
</li>
<li><strong>dependencies</strong>
changed from <em>12171</em> to <em>#12171</em>
</li>
</ul>
<p>
on a 32-bit Pentium 4, after applying <a class="closed ticket" href="https://trac.sagemath.org/ticket/12171" title="enhancement: Update MPFI to 1.5.1 (closed: fixed)">#12171</a> and importing this spkg, I get when I start Sage:
</p>
<pre class="wiki">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.
</pre><p>
Maybe I should first import this spkg then that of MPFI?
</p>
<p>
Paul
</p>
TicketjpfloriMon, 09 Jan 2012 08:32:09 GMT
https://trac.sagemath.org/ticket/11666#comment:22
https://trac.sagemath.org/ticket/11666#comment:22
<p>
Still about the spkg itself:
</p>
<ul><li>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 <a class="closed ticket" href="https://trac.sagemath.org/ticket/3537" title="defect: Change $RM in sage-env (closed: fixed)">#3537</a>
</li><li>MAKE is set back to make before running "make install" (and then "make check" in the original package), any undocumented reason?
</li></ul><p>
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.
</p>
TicketjpfloriMon, 09 Jan 2012 10:30:57 GMT
https://trac.sagemath.org/ticket/11666#comment:23
https://trac.sagemath.org/ticket/11666#comment:23
<p>
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.
</p>
<p>
It can be found at
</p>
<p>
<a class="ext-link" href="http://perso.telecom-paristech.fr/sage/mpfr-3.1.0.spkg"><span class="icon"></span>http://perso.telecom-paristech.fr/sage/mpfr-3.1.0.spkg</a>
</p>
<p>
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.
</p>
TicketleifMon, 09 Jan 2012 22:01:00 GMT
https://trac.sagemath.org/ticket/11666#comment:24
https://trac.sagemath.org/ticket/11666#comment:24
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11666#comment:23" title="Comment 23">jpflori</a>:
</p>
<blockquote class="citation">
<p>
It can be found at
</p>
<p>
<a class="ext-link" href="http://perso.telecom-paristech.fr/sage/mpfr-3.1.0.spkg"><span class="icon"></span>http://perso.telecom-paristech.fr/sage/mpfr-3.1.0.spkg</a>
</p>
</blockquote>
<p>
I do get a 301 to <a class="ext-link" href="http://perso.telecom-paristech.fr/~sage/mpfr-3.1.0.spkg"><span class="icon"></span>http://perso.telecom-paristech.fr/~sage/mpfr-3.1.0.spkg</a> and that gives a 404.
</p>
TicketleifMon, 09 Jan 2012 22:11:54 GMT
https://trac.sagemath.org/ticket/11666#comment:25
https://trac.sagemath.org/ticket/11666#comment:25
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11666#comment:22" title="Comment 22">jpflori</a>:
</p>
<blockquote class="citation">
<p>
Still about the spkg itself:
</p>
<ul><li>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 <a class="closed ticket" href="https://trac.sagemath.org/ticket/3537" title="defect: Change $RM in sage-env (closed: fixed)">#3537</a>.
</li></ul></blockquote>
<p>
Unsetting <code>RM</code> is safe, but meanwhile a bit redundant. Newer autotools use <code>$RM</code> instead of <code>rm -f</code> (or <code>$RM -f</code>), so tend to fail if <code>RM</code> happens to be set to (just) <code>rm</code>.
</p>
<p>
<br />
</p>
<blockquote class="citation">
<ul><li>MAKE is set back to make before running "make install" (and then "make check" in the original package), any undocumented reason?
</li></ul></blockquote>
<p>
I'm pretty sure that's a relict from when people didn't know how to properly disable <em>parallel</em> <code>make</code>. If in doubt, use <code>$MAKE -j1 install</code> etc.
</p>
TicketjpfloriMon, 09 Jan 2012 22:13:52 GMT
https://trac.sagemath.org/ticket/11666#comment:26
https://trac.sagemath.org/ticket/11666#comment:26
<p>
Sorry, this should be <a class="ext-link" href="http://perso.telecom-paristech.fr/~flori/sage/mpfr-3.1.0.spkg"><span class="icon"></span>http://perso.telecom-paristech.fr/~flori/sage/mpfr-3.1.0.spkg</a>
</p>
TicketleifMon, 09 Jan 2012 22:28:45 GMT
https://trac.sagemath.org/ticket/11666#comment:27
https://trac.sagemath.org/ticket/11666#comment:27
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11666#comment:21" title="Comment 21">zimmerma</a>:
</p>
<blockquote class="citation">
<p>
Maybe I should first import this spkg then that of MPFI?
</p>
</blockquote>
<p>
Since MPFI depends on MPFR (and MPIR), you have to rebuild MPFI after upgrading one of the latter.
</p>
<p>
If you have enough time (and/or the machine is fast enough), you can copy new/updated spkgs into <code>$SAGE_ROOT/spkg/standard/</code> and run
</p>
<div class="wiki-code"><div class="code"><pre><span class="nv">$ </span>env <span class="nv">SAGE_UPGRADING</span><span class="o">=</span>yes make build
</pre></div></div><p>
afterwards. That way all dependent packages automatically get rebuilt, which can take some time.
</p>
<p>
(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 <code>spkg-install</code> file written in Python, and Python depends on readline... So a lot of rebuilds performed by <code>make</code> aren't really necessary.)
</p>
TicketzimmermaTue, 10 Jan 2012 12:02:40 GMTwork_issues set
https://trac.sagemath.org/ticket/11666#comment:28
https://trac.sagemath.org/ticket/11666#comment:28
<ul>
<li><strong>work_issues</strong>
set to <em>fails on 32-bit</em>
</li>
</ul>
<p>
I tried importing the MPFI spkg+patches (<a class="closed ticket" href="https://trac.sagemath.org/ticket/12171" title="enhancement: Update MPFI to 1.5.1 (closed: fixed)">#12171</a>) and that spkg on top of 4.8.alpha6 on a 32-bit
Pentium 4 and got the following failures:
</p>
<pre class="wiki">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"
</pre><p>
Paul
</p>
TicketzimmermaTue, 10 Jan 2012 12:41:12 GMT
https://trac.sagemath.org/ticket/11666#comment:29
https://trac.sagemath.org/ticket/11666#comment:29
<p>
the failures are most likely due to the fact that the <code>mpfr_urandom</code> and <code>mpfr_urandomb</code>
return identical values on processors with different word size in MPFR 3.1.0
(see <a class="ext-link" href="http://www.mpfr.org/mpfr-3.1.0/#changes"><span class="icon"></span>http://www.mpfr.org/mpfr-3.1.0/#changes</a>).
</p>
<p>
The bad news is that this will need changing the doctests.
</p>
<p>
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).
</p>
<p>
Paul Zimmermann
</p>
TicketjpfloriThu, 12 Jan 2012 10:18:58 GMT
https://trac.sagemath.org/ticket/11666#comment:30
https://trac.sagemath.org/ticket/11666#comment:30
<p>
For the record, Mike's spkg and my updated one both need to be rebased on top of <a class="closed ticket" href="https://trac.sagemath.org/ticket/12131" title="defect: $SAGE_LOCAL/lib and lib64 (closed: fixed)">#12131</a>.
</p>
<p>
I'll take care of that later.
</p>
TicketjpfloriMon, 23 Jan 2012 17:35:49 GMTauthor, work_issues, description changed
https://trac.sagemath.org/ticket/11666#comment:31
https://trac.sagemath.org/ticket/11666#comment:31
<ul>
<li><strong>author</strong>
changed from <em>Mike Hansen</em> to <em>Mike Hansen, Jean-Pierre Flori</em>
</li>
<li><strong>work_issues</strong>
changed from <em>fails on 32-bit</em> to <em>failing doctests for 32 bits</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/11666?action=diff&version=31">diff</a>)
</li>
</ul>
<p>
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 <a class="closed ticket" href="https://trac.sagemath.org/ticket/12131" title="defect: $SAGE_LOCAL/lib and lib64 (closed: fixed)">#12131</a> at the usual address:
</p>
<p>
<a class="ext-link" href="http://perso.telecom-paristech.fr/~flori/sage/mpfr-3.1.0.spkg"><span class="icon"></span>http://perso.telecom-paristech.fr/~flori/sage/mpfr-3.1.0.spkg</a>
</p>
<p>
I guess the issue with doctests is the last step before "needs review"
</p>
TicketjpfloriThu, 16 Feb 2012 08:09:54 GMT
https://trac.sagemath.org/ticket/11666#comment:32
https://trac.sagemath.org/ticket/11666#comment:32
<p>
I guess my last package should be rebased on <a class="closed ticket" href="https://trac.sagemath.org/ticket/12366" title="enhancement: In mpfr, delete old libraries *after* build (closed: fixed)">#12366</a> which has been merged into 5.beta4.
</p>
<p>
Paul, any news on the doctests problems ?
</p>
TicketzimmermaThu, 16 Feb 2012 11:34:42 GMT
https://trac.sagemath.org/ticket/11666#comment:33
https://trac.sagemath.org/ticket/11666#comment:33
<p>
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).
</p>
<p>
Paul
</p>
TicketzimmermaThu, 16 Feb 2012 16:31:02 GMT
https://trac.sagemath.org/ticket/11666#comment:34
https://trac.sagemath.org/ticket/11666#comment:34
<p>
I tried this patch (with dependencies) on top of Sage 4.8 and got several doctests failures:
</p>
<pre class="wiki"> 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
</pre><p>
Can someone reproduce that?
</p>
<p>
Paul
</p>
TicketjpfloriThu, 16 Feb 2012 22:30:25 GMT
https://trac.sagemath.org/ticket/11666#comment:35
https://trac.sagemath.org/ticket/11666#comment:35
<p>
I've begun the test suite. Here are my failures on a Debian amd64 experimental system (on intel core i7) :
</p>
<pre class="wiki">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
</pre><p>
I'll have a look at them tomorrow.
</p>
<p>
Some of them at least are just changes in random output (e. g. real_mpfr and real_mpfi)
</p>
TicketjpfloriThu, 16 Feb 2012 22:33:00 GMT
https://trac.sagemath.org/ticket/11666#comment:36
https://trac.sagemath.org/ticket/11666#comment:36
<p>
Some other look more problematic:
</p>
<pre class="wiki">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 ]
</pre><p>
Maybe because I did not rebuild Pari spkg?
</p>
<p>
Apart from running sage -b I just forced rebuild of libfplll before the above make ptest (because of lack of time).
</p>
<p>
I'll properly rebuild everything tomorrow and rerun the testsuite.
</p>
TicketjpfloriThu, 16 Feb 2012 22:40:08 GMT
https://trac.sagemath.org/ticket/11666#comment:37
https://trac.sagemath.org/ticket/11666#comment:37
<p>
Nevermind, the above is potentially just verbosity and not related to the actual errors
</p>
<pre class="wiki">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)
**********************************************************************
</pre><p>
And the line above defining z implies random so...
</p>
TicketjpfloriFri, 17 Feb 2012 11:59:47 GMT
https://trac.sagemath.org/ticket/11666#comment:38
https://trac.sagemath.org/ticket/11666#comment:38
<p>
On a different system (Debian amd64 experimental on an intel QuadCore2) I get
</p>
<pre class="wiki">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
----------------------------------------------------------------------
</pre><p>
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.
</p>
TicketjpfloriFri, 17 Feb 2012 12:10:45 GMTwork_issues changed
https://trac.sagemath.org/ticket/11666#comment:39
https://trac.sagemath.org/ticket/11666#comment:39
<ul>
<li><strong>work_issues</strong>
changed from <em>failing doctests for 32 bits</em> to <em>correct doctests</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11666#comment:28" title="Comment 28">zimmerma</a>:
</p>
<blockquote class="citation">
<p>
I tried importing the MPFI spkg+patches (<a class="closed ticket" href="https://trac.sagemath.org/ticket/12171" title="enhancement: Update MPFI to 1.5.1 (closed: fixed)">#12171</a>) and that spkg on top of 4.8.alpha6 on a 32-bit Pentium 4 and got the following failures: <code> 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" </code> Paul
</p>
</blockquote>
<p>
My last failures happen in the same files as what you posted some time ago and are always involving some random function.
</p>
<p>
As you posted later, this should be because MPFR changed its behavior.
</p>
<p>
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.
</p>
<p>
The question is whether this change of behavior is actually a problem ?
</p>
<p>
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.
</p>
<p>
If someone could also test the spkg on sunos, solaris, apple or other exotic oses/cpus combinations, that would be more than welcome.
</p>
TicketjpfloriFri, 17 Feb 2012 17:43:48 GMT
https://trac.sagemath.org/ticket/11666#comment:40
https://trac.sagemath.org/ticket/11666#comment:40
<p>
After rebuilding mpir and atlas (which was screwed) on my core i7 setup, here is what I get
</p>
<pre class="wiki">----------------------------------------------------------------------
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
</pre><p>
I guess something went wrong with that installation because the failing doctest in cmdline.pyx really look strange.
</p>
TicketzimmermaFri, 17 Feb 2012 20:11:48 GMT
https://trac.sagemath.org/ticket/11666#comment:41
https://trac.sagemath.org/ticket/11666#comment:41
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11666#comment:27" title="Comment 27">leif</a>:
</p>
<blockquote class="citation">
<p>
If you have enough time (and/or the machine is fast enough), you can copy new/updated spkgs into <code>$SAGE_ROOT/spkg/standard/</code> and run
</p>
<div class="wiki-code"><div class="code"><pre><span class="nv">$ </span>env <span class="nv">SAGE_UPGRADING</span><span class="o">=</span>yes make build
</pre></div></div><p>
afterwards. That way all dependent packages automatically get rebuilt, which can take some time.
</p>
</blockquote>
<p>
should I rename new packages with the old name? Or keep the new name?
For example Sage 4.8 contains <code>mpfi-1.3.4-cvs20071125.p9.spkg</code>. Should I put
<code>mpfi-1.5.1.spkg</code> aside this one, or rename it?
</p>
<p>
Paul
</p>
TicketzimmermaMon, 20 Feb 2012 17:06:15 GMT
https://trac.sagemath.org/ticket/11666#comment:42
https://trac.sagemath.org/ticket/11666#comment:42
<p>
I just ran the doctests on cicero (skynet) with vanilla 4.8 and all of them pass.
</p>
<p>
Paul
</p>
TicketjpfloriTue, 21 Feb 2012 08:20:28 GMT
https://trac.sagemath.org/ticket/11666#comment:43
https://trac.sagemath.org/ticket/11666#comment:43
<p>
Just to confirm my above statements, on a third amd64 ubuntu system, I get the same errors as above, except the two "strange" ones, i.e. cmdline.py and space.py.
</p>
TicketjpfloriTue, 21 Feb 2012 08:29:14 GMT
https://trac.sagemath.org/ticket/11666#comment:44
https://trac.sagemath.org/ticket/11666#comment:44
<p>
And those last tests were on top sage-5.0.beta4
</p>
TicketjpfloriTue, 21 Feb 2012 09:54:02 GMT
https://trac.sagemath.org/ticket/11666#comment:45
https://trac.sagemath.org/ticket/11666#comment:45
<p>
I've had a look at the random MPFR real number generation code and there was indeed a "hack" for 32 bits systems before which requested more bits (31 from randstate doc, although real_mpfr says 32) from MPIR to get an equivalent MPFR behavior. Although, if I force sage to do the same on my 64 bits system (just adding a call to rstate.c_random() unconditionally in real_mpfr), I do not get what 32 bits (and 64 bits) systems used to return (nor what my 64 bits system now return which was to expect).
</p>
<p>
Paul, I'm confused by your last message. By vanilla 4.8, do you mean vanilla+this ticket and dependencies? If that's the case, and I somehow understand correctly the random generation stuff of MPIR and MPFR which should both be hardware independent now, the change I made above should give me a similar behavior as you on a 32 bits system and get no doctest failures.
</p>
<p>
For example the last failing test in real_mpfr used to give
</p>
<pre class="wiki">0.979095507956490
</pre><p>
With this ticket and dependencies, I get (on all of my 64 systems)
</p>
<pre class="wiki">-0.616678906367394
</pre><p>
With the additional call to c_random() I get (on all of my 64 systems)
</p>
<pre class="wiki">0.681934947736557
</pre>
TicketzimmermaTue, 21 Feb 2012 11:09:32 GMT
https://trac.sagemath.org/ticket/11666#comment:46
https://trac.sagemath.org/ticket/11666#comment:46
<blockquote class="citation">
<p>
Paul, I'm confused by your last message. By vanilla 4.8, do you mean vanilla+this ticket and dependencies?
</p>
</blockquote>
<p>
no, I just meant vanilla 4.8. This was just to make sure that potential failing doctests did not fail before this patch.
</p>
<p>
Now with <a class="closed ticket" href="https://trac.sagemath.org/ticket/12171" title="enhancement: Update MPFI to 1.5.1 (closed: fixed)">#12171</a> all doctests still pass (with one timeout even with <code>-long</code>,
for a test taking more than half an hour).
</p>
<p>
I'll now try with this spkg.
</p>
<p>
Paul
</p>
TicketjpfloriTue, 21 Feb 2012 11:31:55 GMT
https://trac.sagemath.org/ticket/11666#comment:47
https://trac.sagemath.org/ticket/11666#comment:47
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11666#comment:46" title="Comment 46">zimmerma</a>:
</p>
<blockquote class="citation">
<p>
no, I just meant vanilla 4.8. This was just to make sure that potential failing doctests did not fail before this patch.
</p>
</blockquote>
<p>
That's good news for the tests I ran above. I guess the piece of hack in real_mpfr should now be removed. Could you try running the tests with and without the c_random() stuff in real_mpfr and post the values you get for the last failing (I guess it will fail as well) in real_mpfr (on 32 bits I mean)?
</p>
<p>
The bad news is that we won't be able (or it will be very hackish???) to reproduce the previous behavior of Sage, thus breaking all use code depending on the deterministic behavior of PRNG.
</p>
TicketzimmermaTue, 21 Feb 2012 11:50:24 GMT
https://trac.sagemath.org/ticket/11666#comment:48
https://trac.sagemath.org/ticket/11666#comment:48
<blockquote class="citation">
<p>
Could you try running the tests with and without the c_random() stuff in real_mpfr [...]
</p>
</blockquote>
<p>
ok, I'll first run the tests with the attached spkg. Currently running
<code>env SAGE_UPGRADING=yes make build</code>, this will take some time since cicero is slow.
</p>
<p>
Paul
</p>
TicketzimmermaTue, 21 Feb 2012 12:15:42 GMT
https://trac.sagemath.org/ticket/11666#comment:49
https://trac.sagemath.org/ticket/11666#comment:49
<p>
Jean-Pierre,
</p>
<blockquote class="citation">
<p>
I've had a look at the random MPFR real number generation code and there was indeed a "hack" for 32 bits systems before which requested more bits (31 from randstate doc, although real_mpfr says 32) from MPIR to get an equivalent MPFR behavior. Although, if I force sage to do the same on my 64 bits system (just adding a call to rstate.c_random() unconditionally in real_mpfr), I do not get what 32 bits (and 64 bits) systems used to return (nor what my 64 bits system now return which was to expect).
</p>
</blockquote>
<p>
this is expected. If you add the call to <code>rstate.c_random()</code> unconditionally,
then on 64-bit systems you will draw 64 extra random bits when the precision mod 64 is between 1 and 32, whereas on 32-bit systems you will draw only 32 extra random bits.
</p>
<p>
In fact, since version 3.1.0, MPFR leaves the GMP random generator in the same state,
whatever the number of bits per limb. See changeset 7133 from MPFR, and
<a class="ext-link" href="http://gmplib.org/list-archives/gmp-devel/2010-September/001642.html"><span class="icon"></span>http://gmplib.org/list-archives/gmp-devel/2010-September/001642.html</a>. Thus the fix is
simply to remove the "gross hack" at lines 930-942 in real_mpfr.pyx.
</p>
<p>
Paul
</p>
TicketjpfloriTue, 21 Feb 2012 12:37:03 GMT
https://trac.sagemath.org/ticket/11666#comment:50
https://trac.sagemath.org/ticket/11666#comment:50
<p>
From what i saw in randstate, c_random calls gmp_urandomb_ui(self.gmp_state, 31).
</p>
<p>
So this has different behaviors on the gmp rand internal state on 32 and 64 bits ?
</p>
<p>
I expected that it didn't, so that adding a call to c_random() even on 64 bits (just to see, I don't plan on integrating it to Sage, removing the hack is indeed the right solution) would produce identical behaviors on 32 and 64 bits, whence my request for you to test it (in fact with the hack and without it, not with a call to c_random added, on 32 bits).
</p>
<p>
I also had little hope that it could revert the real PNRG to its previous behavior for a given seed (in order not to break existing code, outside Sage source tree I mean).
</p>
<p>
Anyway, if the mpfr code changed, its completely understandable that the random output changes, even with the same seed, so this is hopeless and not really harmful (to me at least).
</p>
<p>
Anyway, if you confirm that you get the same values that I get (with no call to c_random at all, ie without the hackish section only running on 32 bits currently), I'll post patches to remove the hack section and correct the doctests.<br />
</p>
TicketzimmermaTue, 21 Feb 2012 12:52:27 GMT
https://trac.sagemath.org/ticket/11666#comment:51
https://trac.sagemath.org/ticket/11666#comment:51
<blockquote class="citation">
<p>
From what i saw in randstate, c_random calls gmp_urandomb_ui(self.gmp_state, 31).
So this has different behaviors on the gmp rand internal state on 32 and 64 bits ?
</p>
</blockquote>
<p>
no it shouldn't. But beware that Sage uses MPIR, not GMP. We should check that MPIR
gives the same behaviour for the random state on 32-bit and 64-bit processors.
</p>
<p>
I'll tell you what I get as soon as <code>make build</code> finished...
</p>
<p>
Paul
</p>
TicketjpfloriTue, 21 Feb 2012 13:15:15 GMT
https://trac.sagemath.org/ticket/11666#comment:52
https://trac.sagemath.org/ticket/11666#comment:52
<p>
The files randbui.c where gmp_urandomb_ui is defined are similar in GMP (5.04) and MPIR (2.1.3.p9 in Sage).
</p>
<p>
They only call _gmp_rand defined in gmp-impl.h which looks quite similar as well (in fact I saw no diff but did not check completely, there could be some black magic somewhere deep enough).
</p>
<p>
From what I see in integer_ring.pyx and more specifically in the _randomize_mpz function where c_random is called as well, there is no different sections for 32 and 64 bits, nor different doctest in randstate.pyx (only rgp from Pari does change), so I guess it is not that unsafe to assume that MPIR behaves the same for both.
</p>
TicketzimmermaTue, 21 Feb 2012 16:58:15 GMT
https://trac.sagemath.org/ticket/11666#comment:53
https://trac.sagemath.org/ticket/11666#comment:53
<p>
Jean-Pierre,
</p>
<p>
the test of <code>real_mpfr</code> failed with a Segmentation fault on cicero. However I get
the following with the "gross hack" on cicero (32-bit Pentium 4):
</p>
<pre class="wiki">
----------------------------------------------------------------------
| Sage Version 4.8, Release Date: 2012-01-20 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
sage: R=RealField(65)
sage: set_random_seed(42)
sage: R.random_element()
0.9396630990748764761
sage: R.random_element()
0.2987261287446042432
</pre><p>
and without the "gross hack":
</p>
<pre class="wiki">
----------------------------------------------------------------------
| Sage Version 4.8, Release Date: 2012-01-20 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
sage: R=RealField(65)
sage: set_random_seed(42)
sage: R.random_element()
0.7846023201112678858
sage: R.random_element()
0.3289891249716495404
</pre><p>
You should be able to reproduce the later on a 64-bit machine.
</p>
<p>
Paul
</p>
TicketjpfloriTue, 21 Feb 2012 17:04:52 GMT
https://trac.sagemath.org/ticket/11666#comment:54
https://trac.sagemath.org/ticket/11666#comment:54
<p>
Indeed.
</p>
<p>
When forcing the call to c_random(), I get
</p>
<pre class="wiki">----------------------------------------------------------------------
| Sage Version 4.8, Release Date: 2012-01-20 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
Loading Sage library. Current Mercurial branch is: mpfr
sage: R=RealField(65)
sage: set_random_seed(42)
sage: R.random_element()
0.9396630990748764761
sage: R.random_element()
0.2987261287446042432
</pre><p>
And with "normal" behavior:
</p>
<pre class="wiki">----------------------------------------------------------------------
| Sage Version 4.8, Release Date: 2012-01-20 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
Loading Sage library. Current Mercurial branch is: mpfr
sage: R=RealField(65)
sage: set_random_seed(42)
sage: R.random_element()
0.7846023201112678858
sage: R.random_element()
0.3289891249716495404
</pre><p>
So everything looks fine, except for the segfault you got.
</p>
<p>
Hopefully, I'll provide patches for removing the hackish section and fixing the doctests tomorrow.
</p>
TicketvbraunTue, 21 Feb 2012 19:19:18 GMTkeywords changed
https://trac.sagemath.org/ticket/11666#comment:55
https://trac.sagemath.org/ticket/11666#comment:55
<ul>
<li><strong>keywords</strong>
<em>sd36</em> added
</li>
</ul>
<p>
We want to work on the FLINT update at Sage Days 36 so I'll give this a try. I have access to a i7-920 running Linux i386 so it would be easy to test.
</p>
TicketvbraunTue, 21 Feb 2012 21:53:53 GMT
https://trac.sagemath.org/ticket/11666#comment:56
https://trac.sagemath.org/ticket/11666#comment:56
<p>
The segfault is from
</p>
<pre class="wiki">sage: R = RealField(2147483647)
</pre><p>
because MPFR contains code like
</p>
<pre class="wiki"> _srcs = (_srcprec + GMP_NUMB_BITS-1)/GMP_NUMB_BITS;
_dests = (_destprec + GMP_NUMB_BITS-1)/GMP_NUMB_BITS - _srcs;
</pre><p>
This gives an int overflow when <code>prec=INT_MAX</code>, and soon after as segfault because the buffer sizes are wrong.
</p>
TicketvbraunTue, 21 Feb 2012 23:49:07 GMTattachment set
https://trac.sagemath.org/ticket/11666
https://trac.sagemath.org/ticket/11666
<ul>
<li><strong>attachment</strong>
set to <em>trac_11666_remove_random_hack.patch</em>
</li>
</ul>
<p>
Initial patch
</p>
TicketvbraunTue, 21 Feb 2012 23:49:29 GMTattachment set
https://trac.sagemath.org/ticket/11666
https://trac.sagemath.org/ticket/11666
<ul>
<li><strong>attachment</strong>
set to <em>trac_11666_fix_random_doctests.patch</em>
</li>
</ul>
<p>
Initial patch
</p>
TicketvbraunTue, 21 Feb 2012 23:51:14 GMTdescription changed
https://trac.sagemath.org/ticket/11666#comment:57
https://trac.sagemath.org/ticket/11666#comment:57
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/11666?action=diff&version=57">diff</a>)
</li>
</ul>
<p>
I think the easiest solution is to limit the maximal precision in Sage to be slightly below 32-bit INT_MAX. The attached patches do that.
</p>
TicketvbraunWed, 22 Feb 2012 00:29:23 GMTstatus, upstream changed
https://trac.sagemath.org/ticket/11666#comment:58
https://trac.sagemath.org/ticket/11666#comment:58
<ul>
<li><strong>status</strong>
changed from <em>needs_info</em> to <em>needs_review</em>
</li>
<li><strong>upstream</strong>
changed from <em>N/A</em> to <em>Reported upstream. Little or no feedback.</em>
</li>
</ul>
<p>
Reported upstream at <a class="ext-link" href="https://gforge.inria.fr/tracker/index.php?func=detail&aid=13918&group_id=136&atid=619"><span class="icon"></span>https://gforge.inria.fr/tracker/index.php?func=detail&aid=13918&group_id=136&atid=619</a>
</p>
TicketvbraunWed, 22 Feb 2012 04:49:46 GMTupstream, author changed; work_issues deleted
https://trac.sagemath.org/ticket/11666#comment:59
https://trac.sagemath.org/ticket/11666#comment:59
<ul>
<li><strong>upstream</strong>
changed from <em>Reported upstream. Little or no feedback.</em> to <em>Reported upstream. Developers acknowledge bug.</em>
</li>
<li><strong>work_issues</strong>
<em>correct doctests</em> deleted
</li>
<li><strong>author</strong>
changed from <em>Mike Hansen, Jean-Pierre Flori</em> to <em>Mike Hansen, Jean-Pierre Flori, Volker Braun</em>
</li>
</ul>
<p>
I ran the doctests on 32-bit and 64-bit machines and they work.
</p>
TicketjpfloriWed, 22 Feb 2012 08:32:02 GMTstatus, reviewer changed; work_issues set
https://trac.sagemath.org/ticket/11666#comment:60
https://trac.sagemath.org/ticket/11666#comment:60
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
<li><strong>reviewer</strong>
changed from <em>Paul Zimmermann</em> to <em>Paul Zimmermann, Jean-Pierre Flori</em>
</li>
<li><strong>work_issues</strong>
set to <em>rebase on #12366</em>
</li>
</ul>
<p>
As I commented above, the current package needs to be rebased on <a class="closed ticket" href="https://trac.sagemath.org/ticket/12366" title="enhancement: In mpfr, delete old libraries *after* build (closed: fixed)">#12366</a>.
</p>
<p>
I'm doing it right now. I'll also fix the MPFI package so everything can finally be merged.
</p>
<p>
I had a look at your patches and have nothing to say :) So once I upload the new spkg, I guess it will be positive_review.
</p>
TicketjpfloriWed, 22 Feb 2012 10:27:15 GMTstatus, description changed; work_issues deleted
https://trac.sagemath.org/ticket/11666#comment:61
https://trac.sagemath.org/ticket/11666#comment:61
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/11666?action=diff&version=61">diff</a>)
</li>
<li><strong>work_issues</strong>
<em>rebase on #12366</em> deleted
</li>
</ul>
<p>
Updated spkg is available at <a class="ext-link" href="http://perso.telecom-paristech.fr/%7Eflori/sage/mpfr-3.1.0.spkg"><span class="icon"></span>http://perso.telecom-paristech.fr/~flori/sage/mpfr-3.1.0.p0.spkg</a>
</p>
TicketjpfloriWed, 22 Feb 2012 10:28:39 GMTdescription changed
https://trac.sagemath.org/ticket/11666#comment:62
https://trac.sagemath.org/ticket/11666#comment:62
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/11666?action=diff&version=62">diff</a>)
</li>
</ul>
<p>
The above link doesn't point to the right file when clicked...
</p>
<p>
<a class="ext-link" href="http://perso.telecom-paristech.fr/%7Eflori/sage/mpfr-3.1.0.p0.spkg"><span class="icon"></span>http://perso.telecom-paristech.fr/~flori/sage/mpfr-3.1.0.p0.spkg</a>
</p>
<p>
This one should be ok.
</p>
TicketjpfloriWed, 22 Feb 2012 11:36:16 GMT
https://trac.sagemath.org/ticket/11666#comment:63
https://trac.sagemath.org/ticket/11666#comment:63
<p>
All test passed on my amd64 system.
</p>
<p>
If someone could have a final look at the updated spkg, I guess this can be finally set as positive_review.
</p>
TicketvbraunWed, 22 Feb 2012 19:58:48 GMTstatus changed
https://trac.sagemath.org/ticket/11666#comment:64
https://trac.sagemath.org/ticket/11666#comment:64
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
<p>
The Solaris patch is applied to the wrong directory, it is currenty doing <code>cp ../patches/mpn_exp.c mpn_exp.c</code> but if you want to overwrite the MPFR source then you should do <code>cp ../patches/mpn_exp.c src/mpn_exp.c</code> (there is a <code>src/src</code> directory in MPFR-3.1.0, this was just <code>src/</code> in the old MPFR). Can you fix this as well?
</p>
TicketvbraunWed, 22 Feb 2012 19:59:47 GMTstatus changed
https://trac.sagemath.org/ticket/11666#comment:65
https://trac.sagemath.org/ticket/11666#comment:65
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
Too fast with positive review ;-)
</p>
TicketzimmermaThu, 23 Feb 2012 08:17:05 GMT
https://trac.sagemath.org/ticket/11666#comment:66
https://trac.sagemath.org/ticket/11666#comment:66
<p>
I wonder why some random tests still differ between 32-bit and 64-bit computers.
Is there any reason?
</p>
<p>
Paul
</p>
TicketzimmermaThu, 23 Feb 2012 08:24:44 GMT
https://trac.sagemath.org/ticket/11666#comment:67
https://trac.sagemath.org/ticket/11666#comment:67
<p>
I tried the patches on top of Sage 4.8 (after <a class="closed ticket" href="https://trac.sagemath.org/ticket/12171" title="enhancement: Update MPFI to 1.5.1 (closed: fixed)">#12171</a>) but the 2nd and 3rd failed to apply:
</p>
<pre class="wiki">
sage: hg_sage.import_patch("trac_11666_reduce_precision_max.patch")
cd "/home/zimmerma/sage-4.8/devel/sage" && sage --hg import "/home/zimmerma/sage-4.8/trac_11666_reduce_precision_max.patch"
applying /home/zimmerma/sage-4.8/trac_11666_reduce_precision_max.patch
patching file sage/rings/real_mpfr.pyx
Hunk #1 FAILED at 183
1 out of 1 hunks FAILED -- saving rejects to file sage/rings/real_mpfr.pyx.rej
abort: patch failed to apply
</pre><p>
and
</p>
<pre class="wiki">
sage: hg_sage.import_patch("trac_11666_fix_random_doctests.patch")
cd "/home/zimmerma/sage-4.8/devel/sage" && sage --hg import "/home/zimmerma/sage-4.8/trac_11666_fix_random_doctests.patch"
applying /home/zimmerma/sage-4.8/trac_11666_fix_random_doctests.patch
patching file sage/misc/randstate.pyx
Hunk #1 FAILED at 54
Hunk #2 FAILED at 85
Hunk #3 FAILED at 221
Hunk #4 FAILED at 233
Hunk #5 FAILED at 254
Hunk #6 FAILED at 276
6 out of 6 hunks FAILED -- saving rejects to file sage/misc/randstate.pyx.rej
abort: patch failed to apply
</pre><p>
Paul
</p>
TicketjpfloriThu, 23 Feb 2012 08:27:05 GMTstatus changed
https://trac.sagemath.org/ticket/11666#comment:68
https://trac.sagemath.org/ticket/11666#comment:68
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
Replying to <a class="ext-link" href="http://trac.sagemath.org/sage_trac/ticket/11666#comment:66"><span class="icon"></span>zimmerma</a>:
</p>
<blockquote class="citation">
<p>
I wonder why some random tests still differ between 32-bit and 64-bit computers. Is there any reason? Paul
</p>
</blockquote>
<p>
You mean in randstate.pyx? I guess that Pari RNG does not behaves the same on 32 and 64 bits. The other tests (MPIR, MPFR, GAP, NTL, Python) looks the same to me, but i might have missed something.
</p>
<p>
The spkg at the usual address is updated, if someone could test that the patch now applies on Solaris :)
</p>
<p>
For Paul: the Sage patches of the ticker did apply for me on top of 5.0.beta4
</p>
TicketzimmermaThu, 23 Feb 2012 16:17:29 GMT
https://trac.sagemath.org/ticket/11666#comment:69
https://trac.sagemath.org/ticket/11666#comment:69
<p>
we decided in the MPFR development version to decrease the maximal value of the precision from 256, i.e., it is now 2<sup>31</sup>-257. You might want to do the same in Sage, so that upgrading to future MPFR versions will not cause any problem.
</p>
<p>
Paul
</p>
TicketvbraunThu, 23 Feb 2012 18:13:32 GMTattachment set
https://trac.sagemath.org/ticket/11666
https://trac.sagemath.org/ticket/11666
<ul>
<li><strong>attachment</strong>
set to <em>trac_11666_reduce_precision_max.patch</em>
</li>
</ul>
<p>
Updated patch to limit precision at 2<strong>31-257 Updated patch to limit precision at 2</strong>31-257 Updated patch to limit precision at 2<strong>31-257
</strong></p>
TicketvbraunThu, 23 Feb 2012 18:28:28 GMTstatus, reviewer changed
https://trac.sagemath.org/ticket/11666#comment:70
https://trac.sagemath.org/ticket/11666#comment:70
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
<li><strong>reviewer</strong>
changed from <em>Paul Zimmermann, Jean-Pierre Flori</em> to <em>Paul Zimmermann, Jean-Pierre Flori, Volker Braun</em>
</li>
</ul>
<p>
Looks good. I'm happy to give the spkg a positive review. Nothing changed in <code>mpn_exp.c</code> except the file location, so I don't foresee any Solaris issues.
</p>
<p>
I've implemented Paul's suggestion about the precision limit, which was the only reviewer complaint. So I'll take it that everyone agrees with positive review ;-)
</p>
<p>
Patches apply cleanly against sage-5.0.alpha4 and alpha5.
</p>
TicketjdemeyerThu, 23 Feb 2012 20:14:58 GMTstatus, dependencies changed
https://trac.sagemath.org/ticket/11666#comment:71
https://trac.sagemath.org/ticket/11666#comment:71
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_work</em>
</li>
<li><strong>dependencies</strong>
changed from <em>#12171</em> to <em>#12171, #12548</em>
</li>
</ul>
<p>
Sorry for the trouble, but this should be rebased to <a class="closed ticket" href="https://trac.sagemath.org/ticket/12548" title="enhancement: In MPFR, don't delete old libraries (closed: fixed)">#12548</a>.
</p>
TicketjpfloriSat, 25 Feb 2012 10:39:35 GMTstatus changed
https://trac.sagemath.org/ticket/11666#comment:72
https://trac.sagemath.org/ticket/11666#comment:72
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
Here you go.
</p>
<p>
Same address as usual.
</p>
TicketjdemeyerSat, 25 Feb 2012 14:47:03 GMTstatus changed
https://trac.sagemath.org/ticket/11666#comment:73
https://trac.sagemath.org/ticket/11666#comment:73
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
<code>SPKG.txt</code> refers incorrectly to <code>mpfr-3.1.0.p1</code>, it should be <code>.p0</code>
</p>
TicketjpfloriSat, 25 Feb 2012 14:51:38 GMTstatus changed
https://trac.sagemath.org/ticket/11666#comment:74
https://trac.sagemath.org/ticket/11666#comment:74
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
Corrected.
</p>
TicketvbraunSat, 25 Feb 2012 20:42:33 GMTstatus, reviewer changed
https://trac.sagemath.org/ticket/11666#comment:75
https://trac.sagemath.org/ticket/11666#comment:75
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
<li><strong>reviewer</strong>
changed from <em>Paul Zimmermann, Jean-Pierre Flori, Volker Braun</em> to <em>Paul Zimmermann, Jean-Pierre Flori, Volker Braun, Jeroen Demeyer</em>
</li>
</ul>
<p>
Looks good!
</p>
TicketzimmermaSun, 26 Feb 2012 22:19:36 GMT
https://trac.sagemath.org/ticket/11666#comment:76
https://trac.sagemath.org/ticket/11666#comment:76
<p>
I'm not sure my advice in comment <a class="ticket" href="https://trac.sagemath.org/ticket/11666#comment:11" title="Comment 11">11</a> to configure MPFR with <code>-disable-thread-safe</code> was taken into account. This might cause problems on various systems, see for example
<a class="ext-link" href="http://www.loria.fr/~zimmerma/software/compilerbugs.html"><span class="icon"></span>http://www.loria.fr/~zimmerma/software/compilerbugs.html</a>
</p>
<p>
In addition, I'm not sure MPFR can be used as multi-thread within Sage.
</p>
<p>
Paul
</p>
TicketjpfloriSun, 26 Feb 2012 22:41:30 GMT
https://trac.sagemath.org/ticket/11666#comment:77
https://trac.sagemath.org/ticket/11666#comment:77
<p>
No, I did not. I just started on top of Mikes package which came before your comment and I don't remmeber that MPFR includes that flag by default. Ill send a new package tomorrow if you think that's needed. Too late for today.
</p>
TicketvbraunSun, 26 Feb 2012 22:43:21 GMTstatus, upstream changed
https://trac.sagemath.org/ticket/11666#comment:78
https://trac.sagemath.org/ticket/11666#comment:78
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_work</em>
</li>
<li><strong>upstream</strong>
changed from <em>Reported upstream. Developers acknowledge bug.</em> to <em>Fixed upstream, but not in a stable release.</em>
</li>
</ul>
<p>
I'm pretty sure we don't use multithreading with MPFR so we can just pass <code>--disable-thread-safe</code> to configure. I'll be happy to review it tomorrow ;-)
</p>
TicketzimmermaMon, 27 Feb 2012 07:54:51 GMT
https://trac.sagemath.org/ticket/11666#comment:79
https://trac.sagemath.org/ticket/11666#comment:79
<p>
Jean-Pierre, the <code>-disable-thread-safe</code> is not needed, but since Sage does not use
multithreading with MPFR, and given the poor support of multithreading by some compilers and operating systems, I recommend disabling thread local storage.
</p>
<p>
Paul
</p>
TicketjpfloriMon, 27 Feb 2012 10:04:31 GMTstatus changed
https://trac.sagemath.org/ticket/11666#comment:80
https://trac.sagemath.org/ticket/11666#comment:80
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
SPKG updated at the same address.
</p>
TicketjpfloriFri, 02 Mar 2012 14:41:31 GMT
https://trac.sagemath.org/ticket/11666#comment:81
https://trac.sagemath.org/ticket/11666#comment:81
<p>
Is there anything preventing this from getting positive review ?
</p>
<p>
The package address did not change, so I've not updated the ticket description.
</p>
TicketzimmermaFri, 02 Mar 2012 16:17:36 GMT
https://trac.sagemath.org/ticket/11666#comment:82
https://trac.sagemath.org/ticket/11666#comment:82
<p>
Here is a review of <code>trac_11666_spkg.patch</code>:
there are small typos in <code>SPKG.txt</code>, which were already there before:
<code>coment</code> should be <code>comment</code>,
<code>occured</code> should be <code>occurred</code>,
<code>reccommened</code> should be <code>recommended</code>.
</p>
<p>
Apart from that, the more important would be to test the modified spkg.
</p>
<p>
If this was already tested by the buildbot, then I will give a positive review.
</p>
<p>
Paul Zimmermann
</p>
TicketjpfloriFri, 02 Mar 2012 17:04:07 GMTstatus changed; work_issues set
https://trac.sagemath.org/ticket/11666#comment:83
https://trac.sagemath.org/ticket/11666#comment:83
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
<li><strong>work_issues</strong>
set to <em>typos</em>
</li>
</ul>
<p>
From <a class="ext-link" href="http://wiki.sagemath.org/buildbot"><span class="icon"></span>http://wiki.sagemath.org/buildbot</a> it seems that the patchbot does not feel concerned by automatically testing spkg and I have no idea how to use Sage facilities to perform automatically such tests. I even think I have no account on the needed machines, so I cannot take care of launching automated tests.
</p>
<p>
Anyway, I'll take the typos into account tomorrow and update the spkg.
</p>
TicketjpfloriFri, 02 Mar 2012 17:16:41 GMTstatus changed
https://trac.sagemath.org/ticket/11666#comment:84
https://trac.sagemath.org/ticket/11666#comment:84
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
In fact I had some time right now and corrected the typos.
</p>
<p>
The package is at the same address as before.
</p>
TicketjpfloriFri, 02 Mar 2012 17:17:46 GMTattachment set
https://trac.sagemath.org/ticket/11666
https://trac.sagemath.org/ticket/11666
<ul>
<li><strong>attachment</strong>
set to <em>trac_11666_spkg.patch</em>
</li>
</ul>
<p>
spkg diff, for review only
</p>
TicketjdemeyerFri, 02 Mar 2012 21:35:30 GMT
https://trac.sagemath.org/ticket/11666#comment:85
https://trac.sagemath.org/ticket/11666#comment:85
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11666#comment:83" title="Comment 83">jpflori</a>:
</p>
<blockquote class="citation">
<p>
From <a class="ext-link" href="http://wiki.sagemath.org/buildbot"><span class="icon"></span>http://wiki.sagemath.org/buildbot</a> it seems that the patchbot does not feel concerned by automatically testing spkg and I have no idea how to use Sage facilities to perform automatically such tests. I even think I have no account on the needed machines, so I cannot take care of launching automated tests.
</p>
</blockquote>
<p>
Yes, there is currently no way to automatically test spkgs.
</p>
TicketvbraunFri, 02 Mar 2012 22:17:57 GMTstatus changed
https://trac.sagemath.org/ticket/11666#comment:86
https://trac.sagemath.org/ticket/11666#comment:86
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
<p>
The current workflow is positive review -> release manage tests beta on build bot. While the authors should of course test patches, you don't have to test it on every supported machine to give a positive review.
</p>
<p>
We did test it on 32 and 6-bit machines which is the most likely source of errors. Specifics for other systems were not changed so its likely that it'll continue to work. I'll give the spell-checked SPKG.txt my positive review.
</p>
TicketjdemeyerSat, 03 Mar 2012 13:50:05 GMT
https://trac.sagemath.org/ticket/11666#comment:87
https://trac.sagemath.org/ticket/11666#comment:87
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11666#comment:86" title="Comment 86">vbraun</a>:
</p>
<blockquote class="citation">
<p>
We did test it on 32 and 6-bit machines which is the most likely source of errors.
</p>
</blockquote>
<p>
Agreed. My impression from Paul Zimmermann's comment was that it hadn't been tested at all.
</p>
TicketjdemeyerSat, 03 Mar 2012 13:50:31 GMT
https://trac.sagemath.org/ticket/11666#comment:88
https://trac.sagemath.org/ticket/11666#comment:88
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11666#comment:86" title="Comment 86">vbraun</a>:
</p>
<blockquote class="citation">
<p>
We did test it on [...] 6-bit machines
</p>
</blockquote>
<p>
Impressive!
</p>
TicketjdemeyerSun, 04 Mar 2012 21:14:48 GMTwork_issues deleted
https://trac.sagemath.org/ticket/11666#comment:89
https://trac.sagemath.org/ticket/11666#comment:89
<ul>
<li><strong>work_issues</strong>
<em>typos</em> deleted
</li>
</ul>
TicketjdemeyerSun, 04 Mar 2012 21:19:40 GMTstatus changed; resolution, merged set
https://trac.sagemath.org/ticket/11666#comment:90
https://trac.sagemath.org/ticket/11666#comment:90
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
<li><strong>merged</strong>
set to <em>sage-5.0.beta7</em>
</li>
</ul>
Ticket