Implement from_integer and to_integer for all finite fields, extending and replacing fetch_int and integer_representation

[yyyyx4]

Finite fields have .fetch_int() to decode integers into finite-field elements by reinterpreting the base-p representation as a polynomial:

sage: F.<t> = GF(7^10)
sage: el = F.fetch_int(2424); el
t^4 + 3*t + 2

However, the inverse operation is a bit cumbersome:

sage: el.polynomial().change_ring(ZZ)(el.parent().characteristic())
2424

In this patch, we add an inverse to .fetch_int(), named .to_integer() in resemblance with the Python method int.to_bytes().

For symmetry, we then rename .fetch_int() to .from_integer(): I, for one, could never remember if .fetch_int() refers to "fetching an element from an int" or "fetching this element into an int", so I think the new name makes a lot more sense.

Also, some code cleanup and optimization while we're at it.

CC: @DaveWitteMorris @slel

Component: finite rings

Author: Lorenz Panny

Branch/Commit: 0eabc46

Reviewer: Kwankyu Lee

Issue created by migration from https://trac.sagemath.org/ticket/33941

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

4c82bfe

rename .fetch_int() to .from_integer()

[sagetrac-git]

Changed commit from e354108 to 4c82bfe

[yyyyx4]

Description changed:

--- 
+++ 
@@ -13,4 +13,8 @@
 2424
 ```
 
-In this patch, we add an inverse to `.fetch_int()`, named `.to_integer()` in resemblance with the Python method `int.to_bytes()`. Also, some code cleanup and optimization while we're at it.
+In this patch, we add an inverse to `.fetch_int()`, named `.to_integer()` in resemblance with the Python method `int.to_bytes()`.
+
+For symmetry, we then rename `.fetch_int()` to `.from_integer()`: I, for one, could never remember if `.fetch_int()` refers to "fetching an element from an int" or "fetching this element into an int", so I think the new name makes a lot more sense.
+
+Also, some code cleanup and optimization while we're at it.

[yyyyx4]

comment:3

I just found out that #31605 already tracks this issue and that binary finite fields have .integer_representation().

This leaves us with three options for naming these methods:

1. .fetch_int() / .integer_representation() [backwards compatible]
2. .from_integer() / .integer_representation() [one deprecation]
3. .from_integer() / .to_integer() [two deprecations]

Personally I'm still in favor of (3) because the others lack symmetry. Opinions?

[videlec]

comment:5

Replying to @yyyyx4:

I just found out that #31605 already tracks this issue and that binary finite fields have .integer_representation().

This leaves us with three options for naming these methods:

1. .fetch_int() / .integer_representation() [backwards compatible]
2. .from_integer() / .integer_representation() [one deprecation]
3. .from_integer() / .to_integer() [two deprecations]

Personally I'm still in favor of (3) because the others lack symmetry. Opinions?

+1 to option 3

[slel]

comment:6

Also +1 for (3) for the sake of symmetry and consistency.

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

c658823	Merge tag '9.7.beta6' into public/implement_inverse_of_finite_field_fetch_int
b340a29	references for .integer_representation(), and use it if available as it's faster
6230ed7	correct file title for NTL binary-field elements

[sagetrac-git]

Changed commit from 4c82bfe to 6230ed7

[yyyyx4]

comment:8

Thanks for the responses! It seems the only remaining question is whether we want to deprecate .integer_representation() or not.

[slel]

comment:9

Replying to @yyyyx4:

[...] whether [...] to deprecate .integer_representation() or not.

The only reason I would see not to would be consistency
with other software.

Do Magma, Maple, Mathematica have similar functions,
and if so how they are named?