Include modular composition for polynomial rings over finite fields

[GiacomoPope]

Modular composition was very slow for polynomial rings over finite fields, so I have exposed and used the functions from NTL / Flint.

Compared to the naive method we see very nice speed ups.

sage: R.<x> = GF(2**127 - 1)[]
sage: f = R.random_element(degree=100)
sage: g = R.random_element(degree=100)
sage: h = R.random_element(degree=50)
sage: %timeit f(g) % h
960 ms ± 10.6 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
sage: %timeit f.modular_composition(g, h)
721 µs ± 10.4 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)
sage: f(g) % h == f.modular_composition(g, h)
True
sage: 
sage: R.<x> = GF((2**127 - 1, 2))[]
sage: f = R.random_element(degree=100)
sage: g = R.random_element(degree=100)
sage: h = R.random_element(degree=50)
sage: %timeit f(g) % h
1.03 s ± 6.74 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
sage: %timeit f.modular_composition(g, h)
29.1 ms ± 346 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)
sage: f(g) % h == f.modular_composition(g, h)
True
sage: 
sage: R.<x> = GF(163)[]
sage: f = R.random_element(degree=100)
sage: g = R.random_element(degree=100)
sage: h = R.random_element(degree=50)
sage: %timeit f(g) % h
1.68 ms ± 39.9 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)
sage: %timeit f.modular_composition(g, h)
283 µs ± 5.27 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)
sage: f(g) % h == f.modular_composition(g, h)
True

Both ./sage -t and ./sage -tox ... are erroring on my new build after 10.4 so I'm going to let the CI catch my typos.

[GiacomoPope]

The CI seems much buggier than last time I contributed... Do either of the above failures have anything to do with this PR?

[kwankyu]

Sorry for the inconveniences. I am fixing doc build check in #38468.

[GiacomoPope]

Appreciate your fix! And it's not a big problem, I only mentioned it to explain why my PR may have silly typos caught by the CI instead of local testing :)

[kwankyu]

Ah, I thought you meant the failure of the doc build workflow. That is not related with your PR.

[GiacomoPope]

Yes -- what i meant was my doc testing locally is also broken at the moment, so I wrote the documentation "blind" so was unsure whether the bug was my end of Sage's end and could not be of much help.

[yyyyx4]

Some LaTeX details, otherwise this looks great. The speedups are very impressive!

[yyyyx4]

One more thought: Would it be more "standard" with respect to existing Sage naming conventions to call this method .compose_mod()?

[GiacomoPope]

So I actually called this precisely compose_mod() when I started, and then I found the function

sage/src/sage/rings/polynomial/polynomial_gf2x.pyx

Line 109 in 0f34773

def modular_composition(Polynomial_GF2X self, Polynomial_GF2X g, Polynomial_GF2X h, algorithm=None):

and I thought it would be weirder to have different names for polynomial classes.

Another option would be to set

compose_mod = modular_composition

For polynomial_gf2x.pyx to have both names available and use compose_mod for these two new classes?

[yyyyx4]

Supporting both seems like an easy way to make everyone happy. That said, I have no strong opinion about it either way.

[GiacomoPope]

I've pushed a change to have the new methods named as compose_mod which is what I would look for in the autocomplete and then bound modular_composition. For the gf2x class I have also defined compose_mod = modular_composition.