Help understanding the relationship between generic and specific types in Flint3

[GiacomoPope]

This is a very broad question, but I will pick something specific just to help make this clear.

In gr_poly.h there are methods for evaluation, and in particular, fast multipoint evaluation using product trees is available for the generic type.

Looking at then specific types, fmpz_mod_poly has both the naive iterative Horner method, but also a faster method building a product tree, which i assume is similar to the above for the generic type. However, this same method seems to be missing for fq_poly, which has no multipoint evaluation at all?

For the cases where it is not implemented for the specific type, can we fall back to the generic type? In the cases where it's implemented for both what happens? What's the relationship between generic_X and specific_X.

My thinking for python-flint, the answer for the above then filters through to how we structure out code.

If we can inherit generic methods on specific types, should we then build from flint_base and implement the generic_types first, and then do things like cdef class fmpz_poly(generic_poly), if we can inherit the available methods?

[oscarbenjamin]

Making the question broader I wonder if we should use the generic types for all polynomials and matrices.

At a base level the scalar types like fmpz, fmpq, fmpz_mod, and fq cannot really be implemented in a purely generic way. We need to have Python types that correspond to each Flint scalar type and they need to have methods, operators etc that are specific to those types.

It should be possible though to use gr_poly or gr_mat rather than having e.g. fmpz_poly, fmpq_poly etc. That way we can have e.g. a single python-flint class that encompasses all the different Flint _poly types and uses Flint's generics for most of the basic methods.

There are some functions in Flint that are specific to one type though e.g. fmpz_mat_snf for computing the Smith Normal Form of a matrix of integers. For these perhaps instead of having methods like M.snf() there could be a function like snf(M) where the function converts the matrix to fmpz_mat internally. This would not require python-flint to expose an fmpz_mat type but just the Cython code in the snf function would need to be able to convert to a C-level fmpz_mat (which I think just means casting the pointer).