Add gr_mat_pow_ui and gr_mat_pow_fmpz, use it in added fmpz_mod_mat_pow_ui

[lgoettgens]

My first contribution from the workshop (I don't have the rights to add the label myself, could someone please do that for me and/or give me the appropriate rights?).

To be used in Nemo in https://github.com/lgoettgens/Nemo.jl/blob/d12b72e291400fe9609706564cdb289eee472943/src/flint/fmpz_mod_mat.jl#L270-L281.

[albinahlback]

I wonder if this should use GR instead? @fredrik-johansson

[fredrik-johansson]

Arguably there should be separate methods fmpz_mod_mat_pow_ui and fmpz_mod_mat_pow_fmpz since it makes sense to raise to a multiprecision exponent here.

I wonder if this should use GR instead? @fredrik-johansson

Currently there is no gr_mat_pow_ui or gr_mat_pow_fmpz to wrap. Until then, this is fine. (One could initialize a matrix ring and use the generic gr_pow_ui / gr_pow_fmpz, but I'd prefer to have specialized gr_mat methods for powering).

[lgoettgens]

Arguably there should be separate methods fmpz_mod_mat_pow_ui and fmpz_mod_mat_pow_fmpz since it makes sense to raise to a multiprecision exponent here.

true, I'll rename the function here to *_ui and work on a fmpz version as well.

I wonder if this should use GR instead? @fredrik-johansson

Currently there is no gr_mat_pow_ui or gr_mat_pow_fmpz to wrap. Until then, this is fine. (One could initialize a matrix ring and use the generic gr_pow_ui / gr_pow_fmpz, but I'd prefer to have specialized gr_mat methods for powering).

I could look into this instead of the writing more or less the same function for different types

[fredrik-johansson]

I could look into this instead of the writing more or less the same function for different types

It's a good idea.

Actually, it would be interesting to compare a direct implementation of gr_mat_pow_ui / gr_mat_pow_fmpz with a version that creates a matrix ring and calls the generic gr_generic_pow_ui_binexp / gr_generic_pow_fmpz_binexp. If the performance difference is negligible with 2x2 matrices, one could just use the more generic approach to save a few lines of code.

One could also have gr_mat_pow_fmpz_sliding wrapping gr_generic_pow_fmpz_sliding. I'm not sure if this should be used by default instead of the binexp algorithm since it uses much more memory, which could be significant when working with large matrices.

[lgoettgens]

I am experiencing a segfault in the fmpz_mod_mat_pow testcase (that now uses gr_mat_pow_ui). Could one of you please have a look if you spot where this could come from? Or give me a pointer on how to track the issue down? Thanks!

[fredrik-johansson]

Looks good. Do you want to do pow_fmpz in the same PR or should we merge this now?

[fredrik-johansson]

The cast was removed on purpose?

[lgoettgens]

by request of @albinahlback in #2189 (comment)

[fredrik-johansson]

LGTM!