Remove the experimental code for RelativeFiniteFieldExtension

[kwankyu]

This ticket removes the experimental class RelativeFiniteFieldExtension that is currently only used in the coding theory modules.

CC: @johanrosenkilde @defeo @jpflori @sagetrac-dlucas

Component: coding theory

Author: Kwankyu Lee

Branch/Commit: 5f9450f

Reviewer: Vincent Delecroix

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

[kwankyu]

Author: Kwankyu Lee

[kwankyu]

Branch: u/klee/24279

[sagetrac-git]

Commit: df211cf

[sagetrac-git]

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

df211cf

Remove relative_finite_field_extension

[johanrosenkilde]

comment:6

This is great - I had completely forgotten, that you had made #24170!

I've just played around with the vector_space() method, and there's one thing confusing me: it seems that the returned vector space representation is unique, as in only created once even if vector_space is called multiple timpes, but I can't seem to figure out why:

sage: F = GF(2^25)
sage: Fbig = F.extension(10)
sage: V = Fbig.vector_space(F)
sage: V2 = Fbig.vector_space(F)
sage: V is V2
True

[kwankyu]

comment:7

Replying to @johanrosenkilde:

This is great - I had completely forgotten, that you had made #24170!

I've just played around with the vector_space() method, and there's one thing confusing me: it seems that the returned vector space representation is unique, as in only created once even if vector_space is called multiple timpes, but I can't seem to figure out why:

sage: F = GF(2^25)
sage: Fbig = F.extension(10)
sage: V = Fbig.vector_space(F)
sage: V2 = Fbig.vector_space(F)
sage: V is V2
True

Why is it confusing? This is normal behavior:

sage: F**2 is F**2
True
sage: F**2
Vector space of dimension 2 over Finite Field in z25 of size 2^25

[johanrosenkilde]

comment:8

Yes, I know. I'm trying to figure out how it got that behaviour. I thought that one had to subclass UniqueRepresentation, but your vector spaces don't seem to do that (neither does FiniteField for that matter, so there's just something about the structure of these parent objects that I don't understand).

[johanrosenkilde]

comment:9

Ah, now I see. I was confused. The vector space you return is simply a normal vector space as in F**2. What's special is the maps you compute, and the matrices stored in these - and they are not unique. In other words, every time you call vector_space, these matrices will be recomputed.

As was the case with RelativeFiniteFieldExtension, if this vector_space is used somewhere inside an object, across multiple method calls to that object, then it's the objects' job to store those maps as private fields.

This is a bit inelegant, but I guess something for the future, and not really relevant to this ticket. The solution we had envisioned in #21413, but where we admittedly didn't get far, would use an algebra-representation (instead of just a vector space), and this parent would store those maps inside it.

[kwankyu]

comment:10

Replying to @johanrosenkilde:

Ah, now I see. I was confused. The vector space you return is simply a normal vector space as in F**2. What's special is the maps you compute, and the matrices stored in these - and they are not unique. In other words, every time you call vector_space, these matrices will be recomputed.

Right.

As was the case with RelativeFiniteFieldExtension, if this vector_space is used somewhere inside an object, across multiple method calls to that object, then it's the objects' job to store those maps as private fields.

It is so now.

This is a bit inelegant, but I guess something for the future, and not really relevant to this ticket. The solution we had envisioned in #21413, but where we admittedly didn't get far, would use an algebra-representation (instead of just a vector space), and this parent would store those maps inside it.

I don't have a clear idea on this issue. I just feel that instead of inventing extensions as in #21413, using (or improving if necessary) the general conversion mechanism in Sage is better. So a "conversion model" keeps all those maps and return one when requested...

[johanrosenkilde]

comment:11

Replying to @kwankyu:

I don't have a clear idea on this issue. I just feel that instead of inventing extensions as in #21413, using (or improving if necessary) the general conversion mechanism in Sage is better. So a "conversion model" keeps all those maps and return one when requested...

Well, #21413 tries to make it possible to represent a mathematical object (ring extensions as algebras over the base ring), which is not currently possible to represent. In that sense it is much more ambitious than #24170. But of course, that same ambition seems to also have killed its progress.

Anyway, all of that has nothing to do with this ticket.

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

4aa6c09

Remove relative_finite_field_extension

[sagetrac-git]

Changed commit from df211cf to 4aa6c09

[kwankyu]

comment:13

Anything to do?

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

656d32d

Remove relative_finite_field_extension

[sagetrac-git]

Changed commit from 4aa6c09 to 656d32d

[mkoeppe]

comment:17

Batch modifying tickets that will likely not be ready for 9.1, based on a review of the ticket title, branch/review status, and last modification date.

[mkoeppe]

comment:19

Setting new milestone based on a cursory review of ticket status, priority, and last modification date.

[sagetrac-git]

Changed commit from 656d32d to 0a05cd4

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

0a05cd4

Remove relative_finite_field_extension

[mkoeppe]

comment:22

Setting a new milestone for this ticket based on a cursory review.

[mkoeppe]

comment:23

Stalled in needs_review or needs_info; likely won't make it into Sage 9.5.

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

5f9450f

Remove relative_finite_field_extension

[sagetrac-git]

Changed commit from 0a05cd4 to 5f9450f

[kwankyu]

comment:25

It is a shame that we have this cleaning ticket still open for years.

Please let this get in.

[videlec]

comment:26

Looks reasonable.

[videlec]

Reviewer: Vincent Delecroix

[kwankyu]

comment:27

Thanks!

[vbraun]

Changed branch from u/klee/24279 to 5f9450f