Allow copying algebraic closure of finite field

[user202729]

Fixes #38988

I choose to make the copy return itself, because that's what GF(p) does at the moment anyway, and the field is immutable.

Not sure how much of a hack for me to implement __copy__ and __deepcopy__ instead of __reduce__, but pickling and unpickling at the moment works well anyway (although it returns a different instance)

📝 Checklist

• The title is concise and informative.
• The description explains in detail what this PR is about.
• I have linked a relevant issue or discussion.
• I have created tests covering the changes.
• I have updated the documentation and checked the documentation preview.

⌛ Dependencies

[github-actions]

Documentation preview for this PR (built with commit 989037c; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

[JohnCremona]

@nbruin ? I don't know about copying

[nbruin]

I'm not sure what the copying behaviour should be for this structure. Reading the intro of the file, there is a very particular reason why the algebraic closure is not UniqueRepresentation. It is EqualityById, which looks like it's not a problem.
This explains why unpickling produces a new instance ... although

k=GF(5)
kbar=k.algebraic_closure()
GF(5).algebraic_closure() == kbar ##True

suggests that indirectly there IS a preferred copy: the one cached on the corresponding prime field.

The fact that multiple copies can exist would suggest that at least deep_copy should be able to produce a separate copy. Perhaps check with Peter Bruin @pjbruin ?

At the moment, only prime finite fields have algebraic closures. As far as I can see, prime finite fields are not formally UniqueRepresentation, but producing a finite field from GF(p) twice does produce identical results. So similarly, perhaps its algebraic closure is effectively also UniqueRepresentation, in which case we might want to fix pickle and then it wouldn't be controversial for copy to just return self.

More particularly:

sage: k=GF(5)
sage: loads(dumps(k)) is k
True
sage: loads(dumps(kbar)) is kbar ## this is more unequal ...
False
sage: loads(dumps(k)).algebraic_closure() is kbar ## than this
True

and I think the following is actually problematic

sage: kbar.prime_subfield().algebraic_closure() is kbar ##one would expect this
True
sage: kcopy = loads(dumps(kbar))
sage: kcopy.prime_subfield().algebraic_closure() is kcopy ## but that's broken on the copy
False

[user202729]

If I understood correctly, the problem is we cannot really fix pickle, otherwise if we dump an element to the disk, exit Sage, reopen it (and thus the computed pseudo-conway_polynomial is different), then there's no consistent way to convert the unpickled element to an element of the (new) GF(p).algebraic_closure().

Unless… we modify pseudo-Conway polynomial code to be deterministic, this is backwards compatible (we never promise it is random!). Still, unpickling elements from previous SageMath's versions won't work — we again need a deprecation period.

Then there are e.g. https://arxiv.org/abs/2107.02257 that allows a different construction — but if I understood correctly

• there's no way to make the new implementation satisfy the condition of pseudo-Conway polynomial:

GF(2^4)(GF(2^8).0 ^ ((2^8-1)/(2^4-1))) == GF(2^4).0

• there's no way to warn the user of a deprecation — how can we tell if the user is relying on the polynomials being pseudo-Conway?

See also #38376

[nbruin]

Choosing pseudo-conway polynomials in a deterministic way would probably allow solving the pickling problems. I don't immediately see why that wouldn't work for existing pickles (do those pickles store the computed Conway polynomials?), but pickle has a "version" system that allows you to recognize old pickles, that you can then reconstruct using a legacy method that you need to register somewhere.

Changing to another implementation can be done with deprecation: just write and install the new code under other names, have a deprecation period where people get a warning if they use the old routines, pushing them to the new (so that would be algebraic_closure and algebraic_closure_new or something like that. After the deprecation period, the old code can be removed (or renamed to algebraic_closure_conway or something like that). Once the names are freed up, you could alias the new code to the original names. If you so desire, you can deprecate the temporary "new" names. That process takes something like 6 years.

Or if you feel that the benefits of the change are large enough to inconvenience some hypothetical users that depend on conwayness then just make the change. But perhaps check beforehand if any of them are vocal.

[user202729]

Actually… if pseudo-Conway polynomials are really randomly chosen, then finite fields with degree greater than 1 cannot be UniqueRepresentation either. Yet:

sage: deepcopy(GF(5^2))
Finite Field in z2 of size 5^2
sage: deepcopy(GF(5^2)) is GF(5^2)
True
sage: loads(dumps(GF(5^2))) is GF(5^2)
True

I think modifying pickle return the algebraic closure itself would be just fine (in practice). Either that or we should modify the pickle behavior for non-prime finite fields.

[pjbruin]

I can think of three "obvious" ways to copy GF(p).algebraic_closure():

1. return the object itself;
2. return another AlgebraicClosureFiniteField_pseudo_conway object with the parameter lattice equal to the pseudo-Conway lattice of the orginal;
3. return another AlgebraicClosureFiniteField_pseudo_conway object with a newly constructed pseudo-Conway lattice.

I guess it would be fine for __copy__() to return either of the first two; __deepcopy__() could perhaps return the third one. That option behaves differently in the sense that the resulting pseudo-Conway lattices could give rise to different defining polynomials for the finite subfields. If we would make __copy__() and/or __deepcopy__() use the second option, it might be wise to modify AlgebraicClosureFiniteField_pseudo_conway to no longer be WithEqualityById, but to compare the corresponding pseudo-Conway lattices.