Caching interface of cdef'd parent classes

3 views
Skip to first unread message

Simon King

unread,
Jul 7, 2010, 11:57:31 AM7/7/10
to sage-devel
Hi!

The _interface_ method of an object usually tries to cache the result
in an attribute __interface (a dictionary indexed by the different
interfaces such as singular, gap,...). This is a problem if the object
is a Cython class that has no attribute __interface.

Example:
sage: P.<a> = QQ[]
sage: gap(P).name()
'$sage2'
sage: p = gap(P)
sage: p.name()
'$sage2'
sage: gap(P).name()
'$sage3'
sage: gap(P).name()
'$sage3'
sage: gap(P).name()
'$sage3'
sage: p = gap(P)
sage: p.name()
'$sage3'
sage: gap(P).name()
'$sage2'

Couldn't one simply add a cpdef attribute __interface to the class
``Parent``?

Or: Couldn't one introduce a method _interface_cache_, returning a
dictionary of interface caches? Then one can modify _interface_ so
that it tries to call _interface_cache_ when __interface results in an
attribute error.

Anyway, the interface representations of a cached object (like a
parent structure) should be cached, IMHO.

Cheers,
Simon

Simon King

unread,
Jul 7, 2010, 12:11:14 PM7/7/10
to sage-devel
On Jul 7, 4:57 pm, Simon King <simon.k...@nuigalway.ie> wrote:
> Couldn't one simply add a cpdef attribute __interface to the class
> ``Parent``?

I tried, but then there is a problem, since some classes deriving from
Parent define __interface as well. So, I guess I'll try the second
idea.

Cheers,
Simon

Mike Hansen

unread,
Jul 7, 2010, 12:20:09 PM7/7/10
to sage-...@googlegroups.com

William spent a lot of time thinking about caching for the Magma
interface. It may be a worthwhile effort to make that more generic to
apply to other interfaces.

--Mike

Simon King

unread,
Jul 7, 2010, 12:38:36 PM7/7/10
to sage-devel
Hi Mike!

On Jul 7, 5:20 pm, Mike Hansen <mhan...@gmail.com> wrote:
> William spent a lot of time thinking about caching for the Magma
> interface.  It may be a worthwhile effort to make that more generic to
> apply to other interfaces.

What I suggest would apply to all interfaces and to all classes
deriving from Parent that use the generic implementation for that
interface.

"Generic" means: You have an interface bla and a parent structure X,
X._bla_init_() is defined (and returns a string), and X._bla_ is *not*
defined. If one defines X._bla_ then one is supposed to take care of
caching, because then the automatic caching is out of the game.

OK, I'll try if the idea works.

Cheers,
Simon

Simon King

unread,
Jul 8, 2010, 7:04:32 AM7/8/10
to sage-devel
Hi!

On Jul 7, 5:38 pm, Simon King <simon.k...@nuigalway.ie> wrote:
> What I suggest would apply to all interfaces and to all classes
> deriving from Parent that use the generic implementation for that
> interface.

My suggestion is now a patch, namely for ticket #2420. It not only
provides the interface cache framework for Parents, but provides a GAP
representation of polynomial rings.

The cache framework is backwards compatible. In particular, sage -
testall passes. Here is a brief account what I suggest to do if you
want to use the interface cache for your favourite Parent structure
and your favourite interface (say, GAP, but it should work perfectly
alike for magma, PARI etc.):

* Do *not* provide a _gap_ method; otherwise you are supposed to take
care of caching, yourself.
* If your parent structure has no _gap_ method but has a _gap_init_
method then you are fine: The interface representation will now be
cached.
* Your _gap_init_ may accept an (optional) argument that tells which
interface instance should be used.

The third point is useful for recursive constructions: Assume you have
a polynomial ring P and have an instance MyGap of GAP (different from
sage.all.gap). For constructing MyGap(P), it makes sense to construct
MyGap(P.base_ring()) first. Since MyGap(P.base_ring()) is cached,
MyGap(P.base_ring()).name() is a short but unique string that can be
used in the string representation returned by P._gap_init_(MyGap).

#2420 is ready for review (hint...).

Unfortunately, in order to make the interface work for polynomial
rings over cyclotomic fields and number fields (the original topic of
the ticket), I had to work on top of five other tickets, namely #9205,
#9438, #9423, #8909 and #5618. Sorry for that, but some of them have a
positive review anyway.

Cheers,
Simon
Reply all
Reply to author
Forward
0 new messages