Closed malb closed 12 years ago
Description changed:
---
+++
@@ -1,3 +1,6 @@
M4RI 20110601 changed the API, so we need to apply a patch as well,
cf. https://bitbucket.org/malb/m4ri/wiki/M4RI-20110601
+
+* **Install** http://sage.math.washington.edu/home/malb/spkgs/libm4ri-20110601.spkg
+* **Apply** [attachment: m4ri_20110601.patch](https://github.com/sagemath/sage-prod/files/10653267/m4ri_20110601.patch.gz)
Dependencies: #11261
I'm a little confused. The spkgs here and at #9562 are both libm4ri, and seem to be numbered backwards (the "earlier" one in the dependency is from 2011).
Okay, I think I figured it out. Sorry for the noise.
I don't know what I did wrong, but I still get the problem with the Symbol not found: _m4ri_swap_bits
while trying to start, even after this patch. I may have done something wrong, but at any rate I can't spend more time on this now, sorry.
Description changed:
---
+++
@@ -1,6 +1,7 @@
M4RI 20110601 changed the API, so we need to apply a patch as well,
cf. https://bitbucket.org/malb/m4ri/wiki/M4RI-20110601
+cf. https://bitbucket.org/malb/m4ri/wiki/M4RI-20110715
-* **Install** http://sage.math.washington.edu/home/malb/spkgs/libm4ri-20110601.spkg
+* **Install** http://sage.math.washington.edu/home/malb/spkgs/libm4ri-20110715.spkg
* **Apply** [attachment: m4ri_20110601.patch](https://github.com/sagemath/sage-prod/files/10653267/m4ri_20110601.patch.gz)
Author: Martin Albrecht
For the record, I tried spkg + patch on t2 and doctests pass.
Description changed:
---
+++
@@ -3,5 +3,5 @@
cf. https://bitbucket.org/malb/m4ri/wiki/M4RI-20110601
cf. https://bitbucket.org/malb/m4ri/wiki/M4RI-20110715
-* **Install** http://sage.math.washington.edu/home/malb/spkgs/libm4ri-20110715.spkg
+* **Install** https://bitbucket.org/malb/m4ri/downloads/libm4ri-20110715.spkg
* **Apply** [attachment: m4ri_20110601.patch](https://github.com/sagemath/sage-prod/files/10653267/m4ri_20110601.patch.gz)
applies & passes doctests with 4.7.1.rc2.
Reviewer: Simon King
Why is the documentation for matrices over GF(2) not part of the reference manual? I think you should use the upgrade to expose the documentation to the audience.
I am not sure this documentation is much use in the reference manual since most of the interesting functions won't show up. Also, these matrices are expected to behave just as other matrices. On the other hand, there are a few - not many - special functions which are only available for GF(2). I'll take a look.
It seems that you agreed in a different ticket (#9562) that this class doesn't need to be in the reference manual? Hence, returning to needs review. Feel free to change it back, though.
I think I can live with not including it into the references. However, currently I am getting segment faults when doctesting on mark (one of the skynet machines). I try to make sure that I properly install everything from scratch again, before reporting details.
I did a forced new installation of the polybori spkg, then of the M4RI spkg, and I also installed the patches. I get on mark:
sage: P.<a,b,c,d,e> = PolynomialRing(GF(2), 5, order='lex')
sage: I1 = ideal([a*b + c*d + 1, a*c*e + d*e, a*b*e + c*e, b*c + c*d*e + 1])
sage: B.<a,b,c,d,e> = BooleanPolynomialRing(5, order='lex')
sage: I2 = ideal([B(f) for f in I1.gens()])
sage: I2.groebner_basis()
---------------------------------------------------------------------------
RuntimeError Traceback (most recent call last)
/home/simonking/SAGE/sage-4.7.1.rc1mark/devel/sage-main/<ipython console> in <module>()
/home/simonking/SAGE/sage-4.7.1.rc1mark/local/lib/python2.6/site-packages/sage/rings/polynomial/pbori.so in sage.rings.polynomial.pbori.BooleanPolynomialIdeal.groebner_basis (sage/rings/polynomial/pbori.cpp:26221)()
RuntimeError: Segmentation fault
Of course, it could be that the problem comes from the polybori spkg. That would be unfortunate, since it is already merged.
Now, I tried to force re-installation of the original polybori spkg. However, that failed as well. I hope that it will not be needed to rebuild all of sage, which takes ages on mark.
I think the issue is that one needs to install stuff in the right order:
sage/libs/polybori/decl.pxd
sage -b
Meanwhile I managed to revert to the original state, and can confirm that, with vanilla sage-4.7.1.rc2 on 32-bit solaris, the segfault above does not occur.
I will now try to do things in the order you suggested: In fact, originally I had installed polybori, then m4ri, then the m4ri patch, and then sage -b (without touching decl.pxd).
But how can the new polybori spkg be merged if apparently it depends on the new m4ri?
The new installation order did the trick, the segfault has gone. I am now repeating the failing doctests.
Or actually I am repeating sage -testall.
Replying to @simon-king-jena:
But how can the new polybori spkg be merged if apparently it depends on the new m4ri?
Hi, the PolyBoRi does not depend on the new M4RI. This version of M4RI breaks binary compatibility with previous M4RI, i.e. we changed how matrices look internally. Hence, for many pieces of software linking against M4RI one needs to rebuild them to make sure they are talking to the right M4RI library in the right way. That's why M4RI and the PolyBoRi is necessary: to tell PolyBoRi to use this new version. I think we need to updated PolyBoRi as well because some macro names changed and PolyBoRi 0.7.1.p4 contains the necessary code to deal with it.
The tests took 84373.7 seconds on mark, and there were a couple of timeouts. However, there was no failure. The segfault that I reported above vanished by installing everything in the right order. On my computer, all tests pass.
Moreover, it is a prerequisite for working with M4RIE (#9562), which I think is a very important contribution - currently, matrices over GF(2e) are painfully slow in Sage.
I think it is ok that the matrices over GF(2) do not have their own section in the reference manual, since there seems that all non-underscore methods are already present for general matrices.
Hence, it is a positive review.
Woot!
I'm upping the priority, since this fixes a serious mathematical bug reported on sage-support.
The directory m4ri
should be added to .hgignore
the updated SPKG fixes this issue.
Description changed:
---
+++
@@ -3,5 +3,5 @@
cf. https://bitbucket.org/malb/m4ri/wiki/M4RI-20110601
cf. https://bitbucket.org/malb/m4ri/wiki/M4RI-20110715
-* **Install** https://bitbucket.org/malb/m4ri/downloads/libm4ri-20110715.spkg
+* **Install** http://sage.math.washington.edu/home/malb/spkgs/libm4ri-20110715.spkg
* **Apply** [attachment: m4ri_20110601.patch](https://github.com/sagemath/sage-prod/files/10653267/m4ri_20110601.patch.gz)
Merged: sage-4.7.2.alpha2
Changed merged from sage-4.7.2.alpha2 to none
On some 32-bit Linux systems (for example, the buildbot machine cicero
), this causes polybori to fail to install:
g++ -o groebner/src/randomset.o -c -O3 -Wno-long-long -Wreturn-type -g -fPIC -ftemplate-depth-100 -O3 -Wno-long-long -Wreturn-type -g -fPIC -DNDEBUG -DHAVE_GD -DHAVE_TR1_UNORDERED_MAP -DPACKED -DHAVE_M4RI -DHAVE_GD -DHAVE_IEEE_754 -DBSD -I/home/jdemeyer/sage-4.7.2.alpha1/local/include -I/home/jdemeyer/sage-4.7.2.alpha1/local/include/python2.6 -Ipolybori/include -ICudd/obj -ICudd/util -ICudd/cudd -ICudd/mtr -ICudd/st -ICudd/epd groebner/src/randomset.cc
In file included from /home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:42,
from /home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/permutation.h:31,
from /home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/m4ri.h:50,
from groebner/src/nf.h:15,
from groebner/src/randomset.cc:11:
/usr/lib/gcc/i686-pc-linux-gnu/4.4.3/include/emmintrin.h:32:3: error: #error "SSE2 instruction set not enabled"
In file included from /home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/permutation.h:31,
from /home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/m4ri.h:50,
from groebner/src/nf.h:15,
from groebner/src/randomset.cc:11:
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h: In function 'void mzd_row_add_offset(mzd_t*, rci_t, rci_t, rci_t)':
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:741: error: '__m128i' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:741: error: '__src' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:741: error: expected primary-expression before ')' token
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:741: error: expected ';' before 'src'
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:742: error: '__dst' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:742: error: expected primary-expression before ')' token
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:742: error: expected ';' before 'dst'
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:743: error: expected primary-expression before 'const'
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:743: error: expected ';' before 'const'
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:746: error: expected ';' before 'xmm1'
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:747: error: 'xmm1' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:749: error: 'eof' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h: In function 'void mzd_combine_even_in_place(mzd_t*, rci_t, wi_t, const mzd_t*, rci_t, wi_t)':
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1190: error: '__m128i' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1190: error: 'a128' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1190: error: expected primary-expression before ')' token
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1190: error: expected ';' before 'a'
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1191: error: 'b128' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1191: error: expected primary-expression before ')' token
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1191: error: expected ';' before 'b'
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1192: error: expected initializer before '*' token
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1195: error: '_mm_xor_si128' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1198: error: 'eof' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h: In function 'void mzd_combine_even(mzd_t*, rci_t, wi_t, const mzd_t*, rci_t, wi_t, const mzd_t*, rci_t, wi_t)':
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1274: error: '__m128i' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1274: error: 'a128' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1274: error: expected primary-expression before ')' token
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1274: error: expected ';' before 'a'
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1275: error: 'b128' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1275: error: expected primary-expression before ')' token
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1275: error: expected ';' before 'b'
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1276: error: 'c128' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1276: error: expected primary-expression before ')' token
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1276: error: expected ';' before 'c'
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1277: error: expected initializer before '*' token
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1280: error: '_mm_xor_si128' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1284: error: 'eof' was not declared in this scope
scons: *** [groebner/src/randomset.o] Error 1
scons: building terminated because of errors.
Can you allow me to read your build on cicero (my username is malb). I don't have a copy of Sage on cicero and it would save me some time.
Changed keywords from none to sd32
Replying to @malb:
Can you allow me to read your build on cicero (my username is malb). I don't have a copy of Sage on cicero and it would save me some time.
It's in /home/buildbot/build/sage/cicero-1/cicero_full/build/sage-4.7.2.alpha2
(should be accessible through NFS on any Skynet machine).
Replying to @jdemeyer:
On some 32-bit Linux systems (for example, the buildbot machine
cicero
), this causes polybori to fail to install:
[...]
Here on my system the old m4ri/config.h
stays when the new libm4ri spkg is installed. Maybe something around polybori picks the outdated file?
Regards, Alexander
Replying to @alexanderdreyer:
Here on my system the old
m4ri/config.h
stays when the new libm4ri spkg is installed. Maybe something around polybori picks the outdated file?
As Jeroen pointed out this is not related. Unfortunately I cannot reproduce this behaviour. Is there some machine on which this occurs, which I may be granted access to?
Replying to @alexanderdreyer:
As Jeroen pointed out this is not related. Unfortunately I cannot reproduce this behaviour. Is there some machine on which this occurs, which I may be granted access to?
The only machine which I know of is 'cicero' on skynet. We could try to get you an account there but it would take a while I guess. Right now, I cannot even log into the machine.
Replying to @malb:
The only machine which I know of is 'cicero' on skynet. We could try to get you an account there but it would take a while I guess. Right now, I cannot even log into the machine.
This would be nice. I'm about to prepare a qemu image for Gentoo x86. But that will last for some time since I have to compile everything from scratch (It's Gentoo.)
I think thing go south from there
/usr/lib/gcc/i686-pc-linux-gnu/4.4.3/include/emmintrin.h:32:3: error: #error "SSE2 instruction set not enabled"
I had a x86 box without sse2 but it is now collecting dust without an OS installed. I will take a look on the closest thing I can get. Actually Steve Trogdon could have a box where this could be tested, I am copying him.
Replying to @kiwifb:
I think thing go south from there
/usr/lib/gcc/i686-pc-linux-gnu/4.4.3/include/emmintrin.h:32:3: error: #error "SSE2 instruction set not enabled"
I had a x86 box without sse2 but it is now collecting dust without an OS installed. I will take a look on the closest thing I can get. Actually Steve Trogdon could have a box where this could be tested, I am copying him.
I get the same failure as comment:33
/storage/strogdon/gentoo/usr/lib/gcc/i686-pc-linux-gnu/4.5.2/include/emmintrin.h:32:3: error: #error "SSE2 instruction set not enabled"
In file included from /storage/sage-python2.6/sage-4.7.2.alpha1/local/include/m4ri/permutation.h:31:0,
from /storage/sage-python2.6/sage-4.7.2.alpha1/local/include/m4ri/m4ri.h:50,
from groebner/src/nf.h:15,
from groebner/src/randomset.cc:11:
...
scons: *** [groebner/src/randomset.o] Error 1
scons: building terminated because of errors.
Error building PolyBoRi.
M4RI should test for SSE2 and only include that header if it is present. Since it worked so far, I assume it still does that. However, we recently switched from HAVE_SSE2
to __M4RI_HAVE_SSE2
and this might be a change that PolyBoRi didn't pick up? However, it shouldn't be PolyBoRi's responsibility to check for SSE2 and hence something goes wrong when including m4ri.h
.
For some reason m4ri_config.h
on cicero has
#define __M4RI_HAVE_SSE2 1
which is totally wrong! I'll investigate.
More data on cicero:
cat /proc/cpuinfo
reports SSE2
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe up pebs bts
but /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/include/emmintrin.h:32:3
complains. I assume this is because neither PolyBoRi nor Sage pass -msse2
when linking against M4RI but -msse2
defines __SSE2__
which is required by emmintrin.h
. But I don't understand yet why the previous version works.
I can confirm that passing -msse2
fixes the issue. I guess I'll have to find a way to save the flags (to disc?) such that third parties (PolyBoRi, Sage) can re-use them? Any suggestions on how to do that?
Replying to @malb:
I can confirm that passing
-msse2
fixes the issue. I guess I'll have to find a way to save the flags (to disc?) such that third parties (PolyBoRi, Sage) can re-use them? Any suggestions on how to do that?
For scons-bases builds (PolyBoRi as well as Sage) I should be able to provide a suitable code snipplet which checks whether __M4RI_HAVE_SSE2 is defined in m4ri/m4ri_config.h.
We have added some configuration for this here: https://bitbucket.org/brickenstein/polybori/changeset/e5ecbbe5a904 I'll backport this to 0.7.1 and bundle a new spkg asap.
PS: I'm also checking things like sse3 which m4ri might or might not use in the future.
Hi Alexander,
so your plan is to parse for __M4RI_HAVE_SSE2=1
and then pass -msse2
manually? The only caveat I could see with that approach is that it limits us to use !GCC. For Sage this isn't really a problem. M4RI supports more compilers. How's that for PolyBoRi?
If we want to support more compilers I was thinking about dumping the CFLAGS to disk in M4RI which third party tools then can re-use. I was thinking of using the pkg-config.rc file which one can then either use via pkg-config or parse oneself.
PS: Sage's main build scripts are not !Scons based, but I can certainly take care of those.
Replying to @malb:
The only caveat I could see with that approach is that it limits us to use !GCC. For Sage this isn't really a problem. M4RI supports more compilers. How's that for PolyBoRi?
We support only gcc yet. In the case that we would add additional ones we'll add a mapping of non-default compiler options anyway. (e.g. -msse2 -> -xarch-sse2 for sun studio). But if you could export the original parameters, this would of course be better.
If we want to support more compilers I was thinking about dumping the CFLAGS to disk in M4RI which third party tools then can re-use. I was thinking of using the pkg-config.rc file which one can then either use via pkg-config or parse oneself.
I would prefer if you could add a macro defining the options as a string literal to m4ri_config.h. But if you need to setup the rc file anyway, you do not have to duplicate work.
Replying to @malb:
I can confirm that passing
-msse2
fixes the issue. I guess I'll have to find a way to save the flags (to disc?) such that third parties (PolyBoRi, Sage) can re-use them? Any suggestions on how to do that?
Take a look at GMP's / MPIR's gmp.h
and the various libs (like e.g. MPFR) that use it:
$ egrep -B1 "__GMP_(CC|CFLAGS)" /usr/include/gmp.h
/* Define CC and CFLAGS which were used to build this version of GMP */
#define __GMP_CC "gcc -std=gnu99"
#define __GMP_CFLAGS "-march=native -g -O3"
I for example use (slightly OT):
# We eventually use / add these settings (or parts of them) to "our" CFLAGS,
# e.g. "-march=..." or "-mcpu=..." and "-mtune=..." to let gcc generate better,
# processor-specific code, since ECM doesn't use them if we set our own:
gmp_cc_pat='/^[ ]*#[ ]*define[ ]\+__GMP_CC[ ]\+/s/.*"\([^"]*\)"/\1/p'
gmp_cflags_pat='/^[ ]*#[ ]*define[ ]\+__GMP_CFLAGS[ ]\+/s/.*"\([^"]*\)"/\1/p'
gmp_cc=`sed -n -e "$gmp_cc_pat" "$SAGE_LOCAL"/include/gmp.h`
gmp_cflags=`sed -n -e "$gmp_cflags_pat" "$SAGE_LOCAL"/include/gmp.h`
system_gmp_h=""
for incdir in /usr/include /usr/local/include; do
if [ -f $incdir/gmp.h ]; then
system_gmp_h=$incdir/gmp.h
fi
done
if [ -n "$system_gmp_h" ]; then
system_gmp_cc=`sed -n -e "$gmp_cc_pat" $system_gmp_h`
system_gmp_cflags=`sed -n -e "$gmp_cflags_pat" $system_gmp_h`
fi
...
else
# 'native' not supported, see if GMP / MPIR provides us some CPU type:
for opt in $gmp_cflags; do
case $opt in
-march=*|-mcpu=*|-mtune*)
echo "Found CPU parameter in gmp.h: $opt"
cpu_params="$cpu_params $opt"
;;
# perhaps add other options, too (e.g. for different compilers)
*) other_gmp_cflags="$other_gmp_cflags $opt"
esac
done
fi
# Only add them if CFLAGS do not already contain similar:
if [ -n "$cpu_params" ] &&
! (echo "$CFLAGS" | egrep -- '-march=|-mcpu=|-mtune=' >/dev/null);
then
echo "Using additional host-specific CFLAGS: $cpu_params"
CFLAGS="$cpu_params $CFLAGS"
fi
if [ -n "$other_gmp_cflags" ]; then
echo "Not using other CFLAGS provided by gmp.h: $other_gmp_cflags"
fi
...
Putting at least the necessary flags into libm4ri.pc
is of course another, non-exclusive option, and even on systems that lack pkg-config
, you could use the .pc
file by adding a few lines of shell, Python or whatever code.
You can also test whether adding -msse2
(if using SSE2 is desired) is necessary at all, or supported (for simplicity, here gcc
-specific):
# Test whether '-msse2' is supported at all:
if $CC -msse2 -c -x c /dev/null -o /dev/null &>/dev/null; then
# Ok, supported. Do we need it?
# [Should perhaps check whether __SSE2__ is really non-zero.]
if ($CC -E -dM -x c /dev/null | grep -w __SSE2__) &>/dev/null; then
# Fine, we don't need to pass any options to enable SSE2.
required_cflag=""
else
required_cflag="-msse2"
fi
# Check whether the flag conflicts with others, perhaps specified by the user:
if $CC $CFLAGS $required_cflag -c -x c /dev/null -o /dev/null &>/dev/null; then
# Ok, compatible and sufficient.
else
# Conflicting flags, issue error message or try something else...
fi
else
# Not supported, perhaps disable use of SSE2.
fi
(The same tests can easily be performed from Python as well, e.g. in [Sage's] setup.py
or module_list.py
. You could also steal macros from autotools.)
M4RI 20110601 changed the API, so we need to apply a patch as well,
cf. https://bitbucket.org/malb/m4ri/wiki/M4RI-20110601 cf. https://bitbucket.org/malb/m4ri/wiki/M4RI-20110715
Depends on #11261 Depends on #11756
CC: @strogdon @nexttime @alexanderdreyer
Component: packages: standard
Keywords: sd32
Author: Martin Albrecht
Reviewer: Simon King, Alexander Dreyer
Merged: sage-4.7.2.alpha3
Issue created by migration from https://trac.sagemath.org/ticket/11574