#2420: Extending the gap interface to uni- and multivariate polynomial rings
over
number fields
---------------------------+------------------------------------------------
Reporter: SimonKing | Owner: SimonKing
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-4.5
Component: interfaces | Keywords: gap interface, polynomial rings,
number fields, interface cache
Author: Simon King | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
---------------------------+------------------------------------------------
Changes (by SimonKing):
* keywords: gap interface, polynomial rings, number fields,
editor_mhansen => gap interface, polynomial
rings, number fields, interface cache
* status: needs_work => needs_review
* work_issues: Consider stacks of polynomial rings over number fields =>
Comment:
Finally it seems to work. {{{sage -testall}}} passes for me.
First of all, I assume the result of various other tickets that are
related with the GAP interface. To be precise: Before creating my patch, I
did
{{{
hg_sage.import_patch('http://trac.sagemath.org/sage_trac/raw-
attachment/ticket/9205/trac_9205-discrete_log.patch')
hg_sage.import_patch('http://trac.sagemath.org/sage_trac/raw-
attachment/ticket/9205/trac_9205-doctest.patch')
hg_sage.import_patch('http://trac.sagemath.org/sage_trac/raw-
attachment/ticket/9438/trac_9438_IntegerMod_log_vs_PARI.patch')
hg_sage.import_patch('http://trac.sagemath.org/sage_trac/raw-
attachment/ticket/9423/trac_9423_gap_for_numberfields.patch')
hg_sage.import_patch('http://trac.sagemath.org/sage_trac/raw-
attachment/ticket/8909/8909_gap2cyclotomic.patch')
hg_sage.import_patch('http://trac.sagemath.org/sage_trac/raw-
attachment/ticket/8909/trac_8909_catch_exception.patch')
hg_sage.import_patch('http://trac.sagemath.org/sage_trac/raw-
attachment/ticket/5618/trac_5618_gap_for_cyclotomic_fields.patch')
}}}
'''__Interface cache framework for Parents__'''
At [http://groups.google.com/group/sage-
devel/browse_thread/thread/92a66b8e67eeae9b sage-devel], I announced to
introduce a general framework for caching interface representations for
parents. It works like this:
* The class {{{Parent}}} gets two new methods {{{_get_interface_cache_}}}
and {{{_set_interface_cache_}}} that do exactly what the name suggests.
* The method {{{_interface_}}}, defined on the level of Sage Objects,
used to test whether there is an attribute {{{__interface}}} for caching.
It still does, for backwards compatibility. If this fails, it now tries to
call the new cache methods for parents.
* Originally, the {{{_interface_}}} method, applied to an interface
{{{foo}}} would call a method {{{_foo_init_}}} without additional
argument. {{{_foo_init_()}}} is supposed to return a string, that is then
used to call {{{foo}}}. I suggest that {{{_foo_init_}}} is called with the
argument {{{foo}}} - see below why I think this is a good idea. Of course,
many {{{_*_init_}}} methods don't accept an additional argument; we catch
the error and thus have backwards compatibility.
'''__GAP representation of polynomial rings__'''
Polynomial rings can be quite complicated: The base ring might be not as
simple as the rational field. You may even have a tower of polynomial
rings.
In order to represent a polynomial ring with a complicated base ring in
GAP, it seems reasonable to take a recursive approach: First represent the
base ring in GAP, than form a polynomial ring over it.
Since {{{self._gap_init_()}}} is supposed to return a string, we need a
string that determines the GAP representation of {{{self.base_ring()}}}.
Since (with my patch) the interface is cached for parents,
{{{gap(self.base_ring()).name()}}} does the job and is quite efficient
(i.e., short). Problem: It may be that we have a non-standard instance of
the GAP interface. Therefore, I suggest to provide {{{_gap_init_}}} with
an optional argument {{{gap}}}, so that {{{gap(self.base_ring())}}} lives
in the right GAP instance.
Example:
{{{
sage: from sage.interfaces.gap import Gap
sage: MyGap = Gap()
sage: MyGap is gap
False
sage: F.<zeta> = CyclotomicField(8)
sage: P.<x,y> = F[]
sage: a = gap(3)
sage: P._gap_init_(gap)
'PolynomialRing($sage2,["x","y"])'
sage: P._gap_init_(MyGap)
'PolynomialRing($sage1,["x","y"])'
sage: gap('$sage1')
3
sage: MyGap('$sage1')
CF(8)
}}}
'''__GAP interface for polynomials__'''
While the interface representations for Parents should be cached, I think
the representations for elements should (in general) not be cached. So, I
don't use a general framework here, I just provide a {{{_gap_}}} method
that requires one argument, namely the GAP instance to be used.
At [http://groups.google.com/group/sage-
devel/browse_thread/thread/a5761e7bf438cc98 sage-devel], I asked whether
the variable names of a polynomial ring should be automatically inserted
into the GAP interface (currently, they ''are'' inserted).
There was no answer. But I believe that automatic insertion of common
qualifiers like {{{x,t}}} is bad practice.
So, instead of sending the string representation of a polynomial {{{p}}}
to GAP, I compute {{{gap(p)}}} by adding representations of its terms; and
for the terms, I access the variables of {{{gap(p.parent())}}} by position
(rather than by name).
I am not sure if this is the best solution. Anyway, the following now
works and is doctested:
{{{
Multivariate polynomial over a cyclotomic field::
sage: F.<zeta> = CyclotomicField(8)
sage: P.<x,y> = F[]
sage: p = zeta + zeta^2*x + zeta^3*y + (1+zeta)*x*y
sage: gap(p) # indirect doctest
(1+E(8))*x*y+E(4)*x+E(8)^3*y+E(8)
Multivariate polynomial over a number field::
sage: Q.<t> = QQ[]
sage: K.<tau> = NumberField(t^2+t+1)
sage: P.<x,y> = K[]
sage: p = tau + tau^2*x + tau^3*y + (1+tau)*x*y
sage: p
(tau + 1)*x*y + (-tau - 1)*x + y + (tau)
sage: gap(p) # indirect doctest
(tau+1)*x*y+(-tau-1)*x+y+tau
Multivariate polynomial over a polynomial ring
over a number field::
sage: S.<z> = K[]
sage: P.<x,y> = S[]
sage: p = tau + tau^2*x*z + tau^3*y*z^2 + (1+tau)*x*y*z
sage: p
((tau + 1)*z)*x*y + ((-tau - 1)*z)*x + z^2*y + tau
sage: gap(p) # indirect doctest
((tau+1)*z)*x*y+((-tau-1)*z)*x+z^2*y+tau
}}}
Sorry I made this ticket depend on five other tickets, but I think it is
worth it, because most of the above examples didn't work ''at all''.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/2420#comment:10>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
