#14990: Implement algebraic closures of finite fields
-------------------------------------+-------------------------------------
Reporter: pbruin | Owner:
Type: enhancement | Status: needs_info
Priority: major | Milestone: sage-6.2
Component: algebra | Resolution:
Keywords: finite field | Merged in:
algebraic closure | Reviewers:
Authors: Peter Bruin | Work issues:
Report Upstream: N/A | Commit:
Branch: u/pbruin/14990 | 785c7b90031db8fc32b5a271e5bca538027bcfc1
Dependencies: #14958, #13214 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by pbruin):
Hello Vincent,
> Sorry, the story started already long time ago. I would be happy to
finish the review of this ticket and work again on #15390 (no trouble
about the possible rebase, I will try the cherry-pick proposed by Luca).
Great!
> In case you do not want to recompile your Sage over the 6.2.rc0, I put a
version that merge the develop release at u/vdelecroix/14990 (with some
extra, see below).
OK, we should probably switch to that branch (although merging the latest
development branch is only necessary in case of conflicts, and it clutters
the history).
> I am in trouble because of the `UniqueFactory`. Firstly, in some
doctests there is a direct call to
`AlgebraicClosureFiniteField_pseudo_conway` but in practice this should be
avoided as we have
> {{{
> sage: F = AlgebraicClosureFiniteField_pseudo_conway(GF(5),'z')
> sage: z = F.an_element()
> sage: z == loads(dumps(z))
> False
> }}}
> I had no idea how to make it clear.
It is hopefully clear from the general structure, and the fact that these
classes are not in the global namespace, that they are not meant to be
called directly. I do not find it too important, but we can add a remark
if you think it is useful. The above behaviour is quite bad, though...
> On the other hand, what it the purpose of a factory if there is only one
implementation? Note that there will be a problem with the generic
`__reduce__` when there will be several implementations and I am pretty
sure that many others trouble will show up.
There are indeed problems here. First, looking at the code again, I think
that in the current implementation, the interaction between the factory
and the pickling code is flawed. Second, I have been thinking about
unique representation in other contexts (e.g. number fields and elliptic
curves), and there seems to be something more fundamentally problematic.
From my perspective, the guiding philosophy should be that you can use
`UniqueRepresentation` or `UniqueFactory` for objects that are defined
''up to unique isomorphism'' by a certain amount of "defining data", which
corresponds to the arguments of the `__init__()` method of an object
derived from `UniqueRepresentation`, resp. to the `key` used by a
`UniqueFactory`.
The problem with of algebraic closures of finite fields is that in
principle they are ''not'' defined up to unique isomorphism by a finite
amount of defining data. This is exactly the reason why Conway
polynomials were invented, and we could have unique representation if we
only used Conway polynomials. However, the idea of this implementation
was to use ''pseudo''-Conway polynomials, which do not have the same
uniqueness property.
It is not clear to me at the moment that trying to get unique
representation at all in this case is the right thing to do. Especially
with the current implementation, given that pseudo-Conway polynomials are
not unique, it may be better to just (1) ensure that pickling works and
(2) put some warnings in place that algebraic closures are not globally
unique and that users should be careful if they want to ensure all
elements live in the same algebraic closure.
--
Ticket URL: <http://trac.sagemath.org/ticket/14990#comment:58>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
