Conversion from Sage polynomial to gap/libgap

[vdelecroix]

It is not possible to use (in a straightforward way) univariate polynomial in libgap

sage: R.<x> = ZZ[]
sage: libgap(x^5+2*x+1)
Traceback (most recent call last):
...
ValueError: libGAP: Error, Variable: 'x' must have a value

And multivariate polynomials with either gap or libgap

sage: R.<x,y> = ZZ[]
sage: gap(x+y)
Traceback (most recent call last):
...
TypeError: Gap produced error output
sage: libgap(x+y)
Traceback (most recent call last):
...
ValueError: libGAP: Error, Variable: 'x' must have a value

The above ticket (partially based on #2420) implement the above conversions.

Note: The conversion from gap/libgap to Sage does not work as well and will be dealt with in #21020.

[vdelecroix]

New commits:

​f1b8bcd

Trac 18266: Sage polynomial -> gap/libgap polynomial

[tscrim]

It looks good except for _coerce_map_from_. I don't think it is a good idea to have libgap have a coerce map from everything; there are many algebras that (lib)gap almost certainly has no idea about (e.g., Jordan algebras).

[vdelecroix]

• coercion between interfaces objects and Sage objects should be one way. So if for a given ring there is a coercion Sage -> GAP then it should be the case for every ring that GAP understands.

• The solution I used is precisely what is done with PARI/GP (see for instance the PariInstance class in /sage/libs/pari/pari_instance.pyx)

• Implementing the function _coerce_map_from_ would be a useless pain

• "interface objects" are only intended for people having a knowledge of the underlying software

Now, if for some specific GAP object you want to lift it back to Sage then you can either use conversion (i.e. MyParent(my_interface_object)) or use the .sage() method

sage: pari(13).sage()
13
sage: parent(_)
Integer Ring
sage: gap(13).sage()
13
sage: parent(_)
Integer Ring
sage: libgap(13).sage()
13
sage: parent(_)
Integer Ring

[tscrim]

The problem with unlimited coercion maps is that we get a bad (IMO incorrect) error message (this is on develop):

sage: cat = Algebras(QQ).WithBasis().FiniteDimensional()
sage: C = CombinatorialFreeModule(QQ, ['x','y','z'], category=cat)
sage: J1 = JordanAlgebra(C, names=['a','b','c'])
sage: J1.an_element() + gap(2)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
...
TypeError: unsupported operand parent(s) for '+': 'Jordan algebra of Free module generated by {'x', 'y', 'z'} over Rational Field' and 'Gap'
sage: J1.an_element() + pari(2)
---------------------------------------------------------------------------
PariError                                 Traceback (most recent call last)
...
PariError: incorrect type in gtos [integer expected] (t_POL)

There should be a conversion, but I think a coercion is far too strong. Perhaps we should ask sage-devel?

[vdelecroix]

It is a good idea to discuss what should we do concerning coercion and external softwares/libraries.

Concerning this ticket, it is very handy that the coercion always go from Sage to third party interfaces

sage: x = polygen(ZZ)
sage: p = x^3 + 2*x + 1
sage: p(pari(2))
13
sage: type(_)
<type 'sage.libs.pari.gen.gen'>

Making explicit the subset of Sage parents that can actually be represented in a given interface might indeed be much better. But certainly harder to write and maintain. The way I choose is the lazy one. The error messages you mentioned are wrong but should never appear if you restrict to "pure Sage functions". If desirable for pari/gap, I guess that implementing it belongs to another ticket.

[vdelecroix]

And this is not the only wrong thing with interfaces. The default implementation of conversion between Sage and the interfaces etc relies on string representations and global variables... which is of course unreliable

sage: R = PolynomialRing(ZZ,('x','y','z'))
sage: p = 3*R.0*R.1 + R.2^3
sage: pari(p).sage()
Traceback (most recent call last):
...
NameError: name 'y' is not defined

or

sage: pari(ZZ).sage()
<built-in function IntegerRing>
sage: pari(RR)
RealFieldwith53bitsofprecision
sage: pari(RR).sage()
Traceback (most recent call last):
...
NameError: name 'RealFieldwith53bitsofprecision' is not defined

[tscrim]

Well, since we already do a catch-all coercion for pari and we got no response from sage-devel, I can tolerate the current state of the coercion.