Replying to jdemeyer:

Replying to SimonKing:

It isn't fixed.

I just pushed a branch fixing exactly the problem that you described and you're not happy because it doesn't also fix *another* issue? Good luck fixing it your way then.

Your behaviour makes me speechless. Almost.

The ticket description is about using the short-cut _mul_long as a solution to the problem that Matrix*int didn't work. As it turns out #24742 allows Matrix*int, but it doesn't do it by enabling _mul_long (although _mul_long is supported in sage.structure.element).

So, given the poor performance I demonstrated, there is an issue here that goes beyond what was fixed in #24742, and it is related with what the ticket description of this ticket says.

In addition, I notice that the current implementation of _mul_long for Matrix_gfpn_dense doesn't convert an integer into `GF(p^n,'x')`

by reduction modulo p, but by some conversion used by MeatAxe. For instance, 4 would be converted to the number x+1 in GF(9,'x'). I didn't notice it before since in my cohomology applications I work with matrices over prime fields, where the different conversions happen to coincide.

Hence, if this ticket is about to "Fix Matrix_gfpn_dense*int", then here one should

- re-enable the usage of _mul_long for matrix times int, because of the performance issue
- fix _mul_long of Matrix_gfpn_dense for non-prime fields.

I changed the ticket description accordingly.

Consequently, this ticket is by no means just a duplicate of #24742.

And even when you insist that it is a duplicate: What would be the point of closing this ticket as a duplicate (or maybe just adding a test) and then opening yet another ticket that deals with the two remaining issues?

Alternatively, I could just leave the issues alone and use ._mul_long directly in my cohomology code, to be independent of whatever implementation of coercion is currently used.