Re: M2 algorithm for GB is broken (?)

[Martin Albrecht]

Hi William,

I tried to fix the bug and provided a patch at

http://trac.sagemath.org/sage_trac/attachment/ticket/14587/

However, I cannot test it as the M2 experimental package won't build (on my
machine).

On Tuesday 14 May 2013, William Stein wrote:
> Hi,
>
> I actually tried to use something marked #optional, hence not tested,
> hence broken, and it was broken:
>
> P.<a,b,c> = PolynomialRing(ZZ,3)
> I = sage.rings.ideal.Katsura(P,3) # regenerate to prevent caching
> I.groebner_basis('macaulay2:gb') # optional - macaulay2
>
> Error in lines 3-3
> Traceback (most recent call last):
> File "/mnt/home/lFqBXyPI/.sagemathcloud/sage_server.py", line 412, in
> execute exec compile(block, '', 'single') in namespace, locals
> File "", line 1, in <module>
> File "cachefunc.pyx", line 1462, in
> sage.misc.cachefunc.CachedMethodCaller.__call__
> (sage/misc/cachefunc.c:7556)
> File "cachefunc.pyx", line 2044, in
> sage.misc.cachefunc.CachedMethod._instance_call
> (sage/misc/cachefunc.c:10040)
> File
> "/usr/local/sage/sage-5.9/local/lib/python2.7/site-packages/sage/rings/pol
> ynomial/multi_polynomial_ideal.py", line 3840, in groebner_basis
> gb = self._groebner_basis_macaulay2(prot=prot, *args, **kwds)
> TypeError: _groebner_basis_macaulay2() got an unexpected keyword argument
> 'prot'

Cheers,
Martin

--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
_www: http://martinralbrecht.wordpress.com/
_jab: martinr...@jabber.ccc.de

[Dima Pasechnik]

M2 spkg in Sage is so old (ver 1.1, as opposed to just released 1.6: https://github.com/Macaulay2/M2/tree/release-1.6)

that it's better to completely remove it from the repo...

Just in case, I tried building version 1.6 inside the Sage 5.9 shell, and it didn't work due to some GMP incompatibility:

In file included from /tmp/M2/M2/BUILD/normal/libraries/final/include/stdinc.h:34:0,

                 from ../../../../Macaulay2/d/version.dd:30:

/usr/local/src/sage/sage-5.9/local/include/gmpxx.h: In member function 'intmax_t __gmp_expr<__mpz_struct [1], __mpz_struct [1]>::get_sx() const':

/usr/local/src/sage/sage-5.9/local/include/gmpxx.h:1710:49: error: 'mpz_get_sx' was not declared in this scope

So this is not so easy to get it updated...

[mmarco]

sage-on-gentoo folks have Macaulay2-1.6 working with sage-5.9 fine. So
i wonder why compilation fails inside sage-5.9.

> > _jab: martinr...@jabber.ccc.de <javascript:>

[Volker Braun]

Macaulay2 in Fedora also works perfectly fine with Sage. Its just that the M2 spkg has bitrotted to the point where its useless. And Macaulay2 has a long list of dependencies that we don't carry, so its not just a case of packaging a newer release.

[William Stein]

On Mon, May 20, 2013 at 2:06 AM, Dima Pasechnik <dim...@gmail.com> wrote:
> M2 spkg in Sage is so old (ver 1.1, as opposed to just released 1.6:
> https://github.com/Macaulay2/M2/tree/release-1.6)
> that it's better to completely remove it from the repo...
> Just in case, I tried building version 1.6 inside the Sage 5.9 shell, and it
> didn't work due to some GMP incompatibility:
>
> In file included from
> /tmp/M2/M2/BUILD/normal/libraries/final/include/stdinc.h:34:0,
> from ../../../../Macaulay2/d/version.dd:30:
> /usr/local/src/sage/sage-5.9/local/include/gmpxx.h: In member function
> 'intmax_t __gmp_expr<__mpz_struct [1], __mpz_struct [1]>::get_sx() const':
> /usr/local/src/sage/sage-5.9/local/include/gmpxx.h:1710:49: error:
> 'mpz_get_sx' was not declared in this scope
>
> So this is not so easy to get it updated...

It's an experimental package for a reason... M2 is quite difficult
and time consuming to build.

For https://cloud.sagemath.com I've been just installing M2 using the
Ubuntu binary packages that they provide on their website. It still
works fine from Sage, as far as I can tell.

wget http://www.math.uiuc.edu/Macaulay2/Downloads/Common/Macaulay2-1.6-common.deb

wget http://www.math.uiuc.edu/Macaulay2/Downloads/GNU-Linux/Ubuntu/Macaulay2-1.6-amd64-Linux-Ubuntu-12.04.deb

sudo apt-get install libntl-5.4.2 libpari-gmp3

sudo dpkg -i Macaulay2-1.6-common.deb
Macaulay2-1.6-amd64-Linux-Ubuntu-12.04.deb


Since the M2 developers are doing a good job packaging binaries of M2
for various distros, etc., and Sage doesn't link to M2 at a binary
level in any way, maybe we don't need an M2 spkg.

William

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

[Volker Braun]

For the record: Its 

   yum install Macaulay2

on Fedora.

[mmarco]

So, should we remove the M2 package?

I think it is definitely better to not have it, and let the user
install his own copy of M2, than to have a package that does not work.

[leif]

mmarco wrote:
> sage-on-gentoo folks have Macaulay2-1.6 working with sage-5.9 fine. So
> i wonder why compilation fails inside sage-5.9.

They presumably build it against GMP rather than MPIR.

The *_ux() and *_sx() functions are an extension specific to MPIR AFAIK.


-leif

> On 20 mayo, 11:06, Dima Pasechnik <dimp...@gmail.com> wrote:
>> M2 spkg in Sage is so old (ver 1.1, as opposed to just released 1.6:https://github.com/Macaulay2/M2/tree/release-1.6)
>> that it's better to completely remove it from the repo...
>> Just in case, I tried building version 1.6 inside the Sage 5.9 shell, and
>> it didn't work due to some GMP incompatibility:
>>
>> In file included from
>> /tmp/M2/M2/BUILD/normal/libraries/final/include/stdinc.h:34:0,
>> from ../../../../Macaulay2/d/version.dd:30:
>> /usr/local/src/sage/sage-5.9/local/include/gmpxx.h: In member function
>> 'intmax_t __gmp_expr<__mpz_struct [1], __mpz_struct [1]>::get_sx() const':
>> /usr/local/src/sage/sage-5.9/local/include/gmpxx.h:1710:49: error:
>> 'mpz_get_sx' was not declared in this scope
>>
>> So this is not so easy to get it updated...

--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail

[Nathann Cohen]

Helloooooooo !!

So, should we remove the M2 package?

I think it is definitely better to not have it, and let the user
install his own copy of M2, than to have a package that does not work.

I totally agree with that. We had an argument about the Graphviz spkg on #13624 about the very same problem, and I also think we could do without that one.

Nathann

[Dima Pasechnik]

Does this still mean we need a "plug" spkg, so that Sage knows that M2 is available on the host, 

and so e.g. the interface can be tested automatically?

Dima