Context object for nmod_poly and nmod_mat

[fredrik-johansson]

It's a nuisance that nmod_poly and nmod_mat store the context object inside the struct: this wastes space and interferes with using generic code that works for other polynomial and matrix types. Indeed, n_poly reimplements much of nmod_poly just to have a better interface.

Breaking compatibility probably isn't option here since these types are too widely used outside FLINT itself (maybe for 4.0?). We could, however, move all the logic to an n_poly-like layer and define nmod_poly and nmod_mat functions as trivial wrappers that just forward the context objects. Something like this:

void
n_mod_poly_add(n_mod_poly_t res, const n_mod_poly_t a, const n_mod_poly_t b, nmod_t ctx)
{
    ...
}

NMOD_POLY_INLINE void
nmod_poly_add(nmod_poly_t res, const nmod_poly_t a, const nmod_poly_t b)
{
    n_mod_poly_add(res, a, b, res->mod);
}

Related issues:

• Would it be better to pass nmod_t by reference? Maybe as part of a new interface layer. Not sure if this is better performance-wise, but one advantage is that one could have a larger context object storing things like the factorization of n or a primality flag (like the extended context object in gr).
• Lots of nmod functions currently abort when encountering an impossible inverse. We should put in proper error handling instead.

[albinahlback]

I do like the renaming, so I think this would be very suitable.

Moreover, I do think it would be wise to pass it by reference. For four-inputted functions with one of them being nmod_t, this would mean that on an x86_64-architecture, all values could be passed into registers, but for more inputs, some of them have to be pushed onto the stack. Hence, I think it is wise to pass by reference.

As a sidenote, however, I do not understand (from a performance perspective), why we pass const fmpz by reference. But that's another question.

[albinahlback]

• Lots of nmod functions currently abort when encountering an impossible inverse. We should put in proper error handling instead.

Yes, and we should avoid a lot of text-based error handling as that can significantly increase code size.