Context/Domain objects in python-flint

[oscarbenjamin]

Currently in python-flint the available types are all types that can be implemented without the need for any sort of "context" or "domain" object e.g. fmpz, fmpq, nmod etc. In the case of nmod the modulus is just passed in the constructor e.g. nmod(x, p). Other types like arb etc and the series types use a global context for things that might otherwise be held in local context objects:

python-flint/src/flint/pyflint.pyx

Lines 66 to 83 in 99fa557

	cdef class FlintContext:
	cdef public bint pretty
	cdef public long _prec
	cdef public long _dps
	cdef arf_rnd_t rnd
	cdef public bint unicode
	cdef public long _cap
	def __init__(self):
	self.default()
	def default(self):
	self.pretty = True
	self.rnd = ARF_RND_DOWN
	self.prec = 53
	self.unicode = False
	self.threads = 1
	self.cap = 10

Here cap is a global variable to control the number of terms in series and prec sets the precision used for arb:

In [1]: from flint import *

In [2]: arb(2).sqrt()
Out[2]: [1.41421356237309 +/- 5.15e-15]

In [3]: ctx.prec = 100

In [4]: arb(2).sqrt()
Out[4]: [1.4142135623730950488016887242 +/- 1.08e-29]

In [5]: fmpq_series([0, 1]).exp()
Out[5]: 1 + x + 1/2*x^2 + 1/6*x^3 + 1/24*x^4 + 1/120*x^5 + 1/720*x^6 + 1/5040*x^7 + 1/40320*x^8 + 1/362880*x^9 + O(x^10)

In [6]: ctx.cap = 4

In [7]: fmpq_series([0, 1]).exp()
Out[7]: 1 + x + 1/2*x^2 + 1/6*x^3 + O(x^4)

The other types that should be added like fq and multivariate polynomials will need to have local context objects identifying the ring/field e.g. to store the polynomial for fq or the variable names in the case of multivariate polynomials.

I think that it would be better for a number of reasons if all basic types had context objects and if it could be possible to query types by accessing the context objects and using them for things like conversions and for anything that would otherwise be handled as global state (e.g. prec and cap) or object-local state (e.g. the modulus for nmod). Using contexts is certainly needed for many types but doing it systematically for all types would bring some advantages.

I realise that introducing context objects is potentially a bit of a slippery slope when considering the complex systems that arise in e.g. Sage or in SymPy and I think it is important to keep things simple but I also think that at least something is needed to be able to manage the types programmatically.

Hypothetically let's say that the context objects could be called e.g. fZZ for fmpz, fQQ for fmpq and e.g. fFF(p) for nmod etc. Then the interface for creating e.g. an fmpz_poly could just be fZZ.poly([1, 2, 3]) and likewise fZZ.mat([[1, 2], [3, 4]]) could make a matrix. This would:

• Allow constructors for polynomials and matrices to have the same signature (e.g. no p argument for the poly constructor in fFF(p).poly([1, 2, 3])).
• Remove global state like prec and cap.
• Provide an object that could be used to perform explicit conversions like fQQ.mat([[1, 2], [3, 4]]).convert_to(fZZ) (currently there is no way to convert fmpq_mat to fmpz_mat).
• Provide a way to introspect what sort of object any particular flint type is which could just be as simple as:

  >>> obj.flint_type
  ('poly', fZZ)

• Provide a place to store the Flintcontext that is needed in the case of finite fields (fq) or multivariate polynomials like fmpz_mpoly.

There could still be a global context for certain things e.g. arb but there should be some way to use the arb functions without messing around with global state maybe like:

ctx = ArbCtx(prec=100)
ctx.arb(2).sqrt()

Also it would be good to have function versions of most of the Arb methods and perhaps those could just be methods on a context object so e.g. ctx.sqrt(2) or ctx.besselj(5, 1) rather than arb(5).besselj(1).

Obviously once we have multiple contexts then it creates issues in terms of exactly how the different objects should interoperate and whether there should be implicit conversions. For my own usage of python-flint it is generally better if there are no implicit conversions. The few simple implicit conversions that currently take place are fine but what I really want is a way to control explicit conversions and I think that some kind of context-like objects are needed for that.