Regression in Pari finite field interface

[defeo]

In Sage 6.2

sage: GF(11^23, 'a').gen()^Zmod(11)(1)
1

In 5.9 this used to give

sage: GF(11^23, 'a').gen()^Zmod(11)(1)
a

[jdemeyer]

Do you agree that the correct behaviour is a ValueError?

[pbruin]

PARI's FF_pow requires the exponent to be a t_INT, but does not check the type, and FiniteFieldElement_pari_ffelt.__pow__() does not enforce this either. (Actually it also assumes the exponent to be an integer, since it checks if it is negative.) We could simply convert the exponent into an Integer; the only drawback is that we would have to do a separate check for IntegerMod with an incorrect modulus if we want to raise a ValueError in that case.

[defeo]

Replying to jdemeyer:

Do you agree that the correct behaviour is a ValueError?

I agree that mathematically the operation does not make sense, unless the modulus is equal to the order of the element (but computing it would be overkill in my opinion) or a multiple (the only reasonable one being cardinality - 1).

Now, if we want to raise a ValueError, this is not a Pari issue anymore: it is a huge issue in basically any component of Sage!

sage: 3^Zmod(3)(2)
9
sage: GF(101)(2)^Zmod(3)(2)
4
sage: QQ['x'].gen()^Zmod(3)(2)
x^2
sage: i^Zmod(3)(2)
-1
sage: AbelianGroup([10])[1]^Zmod(3)(2)
f^2

etc...

[pbruin]

Here is a branch to make FiniteFieldElement_pari_ffelt.__pow__() always convert the exponent to an integer. This fixes the following mathematically wrong answer to return a:

sage: q = 11^23
sage: F.<a> = FiniteField(q)
sage: a^Mod(1, q - 1)
1

The new code actually seems to be marginally faster than the old one (about 10% on this example). It also adds a warning to the documentation that we do not check for well-definedness before converting the exponent to an integer.

[vbraun]

Reviewer name