update M4RI to newest upstream release

[malb]

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-20110715.spkg
• Apply m4ri_20110601.patch​

[kcrisman]

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).

[kcrisman]

Okay, I think I figured it out. Sorry for the noise.

[kcrisman]

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.

[malb]

For the record, I tried spkg + patch on t2 and doctests pass.

[malb]

applies & passes doctests with 4.7.1.rc2.

[SimonKing]

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.

[malb]

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.

[malb]

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.

[SimonKing]

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.

[SimonKing]

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.

[SimonKing]

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.

[malb]

I think the issue is that one needs to install stuff in the right order:

• install new M4RI
• install new PolyBoRi?
• apply the M4RI patch
• touch sage/libs/polybori/decl.pxd
• sage -b

[SimonKing]

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?

[SimonKing]

The new installation order did the trick, the segfault has gone. I am now repeating the failing doctests.

[SimonKing]

Or actually I am repeating sage -testall.

[malb]

Replying to SimonKing:

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.

[SimonKing]

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(2^e) 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.

[malb]

Woot!

[was]

I'm upping the priority, since this fixes a serious mathematical bug reported on sage-support.

[jdemeyer]

The directory m4ri should be added to .hgignore

[malb]

the updated SPKG fixes this issue.