Oscar Benjamin

The output on master is now simpler and tests are added for this in #18836. However there are two points that remain from this issue: 1. The complicated output is...

This should be actually working now unlike previous commits. I haven't implemented the prime checks yet but I have changed it so that `nmod`, `nmod_poly` and `nmod_mat` all use context...

> I want to try to get back down to at least the same time if not faster than master. It is potentially not worth slowing down nmod for prime...

> This gives: > > ```python > In [3]: sys.getsizeof(nmod(3, 7)) > Out[3]: 48 > ``` > > That is the same as on master. I'm not sure where that...

After playing around with this a bit I think that it is not possible to store an `nmod_ctx` as a Python object attached to an `nmod` without incurring some overhead....

> That sort of explains why in this PR `nmod` is still 48 bytes rather than 32. It is because the `nmod_ctx` pointer somehow cannot just increase the size from...

> I asked on the Cython mailing list and this is apparently due to cyclic GC: Using `@cython.no_gc` seems to bring some speedups for some benchmarks. > Also here are...

@GiacomoPope @Jake-Moss I don't know if either of you wants to review this. I ended up doing a bunch of somewhat unrelated things like improving the coverage plugin adding tests...

> I've just had a quick read over everything here + the diff but won't have the time this week for a proper review. No problem. There is no rush...

> The `~10` nanoseconds that I worried about for `nmod` are not significant for `nmod_mat` unless perhaps we have very small matrices like 2 x 2 or something. Here is...