#14990: Implement algebraic closures of finite fields
-------------------------------------------------+-------------------------
Reporter: pbruin | Owner:
Type: enhancement | Status:
Priority: major | needs_review
Component: algebra | Milestone: sage-5.13
Keywords: finite field algebraic | Resolution:
closure | Merged in:
Authors: Peter Bruin | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
Dependencies: #14958, #13214 | Stopgaps:
-------------------------------------------------+-------------------------
Comment (by jpflori):
Replying to [comment:7 defeo]:
> Nice work. I agree this is the way to go for Fp-bar. Here's some
thoughts.
>
> 1. It'd be nice to implement a `_latex_` method in the elements.
Sure.
>
> 2. There's a quote problem in the first paragraph of the docstring:
>
> {{{
> '[\Bold{F}_n:\Bold{F}]=1`
> }}}
>
> 3. I'm perplexed about the `_cmp_` function in `conway_polynomials.py`:
>
> {{{
> sage: PCL3 = PseudoConwayLattice(3, use_database=False)
> sage: PCL5 = PseudoConwayLattice(5, use_database=False)
> sage: PCL3 == PCL5
> True
> }}}
>
> Is this the intended result?
>
This looks wrong to me.
> 4. `F.inclusion(1, a).section()` is `None` for any `a`, this makes
`_change_level` fail.
>
> 5. I wonder: wouldn't it be more efficient if `_coerce_2` had a shortcut
for when `x` and `y` are in the same level? (I really don't know, just
wondering)
Stupid rant: I don' like the name _coerce_2, I don't think it really fits
with our current naming scheme, nor that it really suggests what the
function does (I first thought of coerce_to... of course it is two, not
to).
About the shortcut, why not, but it does not seem that urgent.
Maybe we should do some timings.
>
> 6. This patch lacks some obvious coercions, for example,
`F._subfield(2)(F.gen(2))`. Should this wait for another ticket, or should
this ticket do it?
>
Depends on the difficulty? :)
> I'd like to play around with different implementations of Fp-bar. This
would help understand if the abstract class
`AlgebraicClosureFiniteField_generic` is abstract enough, or if we need to
think more carefully about its interface.
>
> I don't know what's best: make this ticket enter 5.13, then start
experimenting? Or, rather, keep experimenting and wait the different
implementations to have settled before giving positive review?
>
> If you want to go for the first, I'd be happy to give positive review as
soon as the minor problems mentioned above are solved. If you prefer the
second option, would you mind switching to git, so to ease collaboration?
I don't really know.
I'm usually for fast inclusion.
But for this one I might be inclined to wait for 6.0 to give it a little
more testing.
In particular, I'd like to make sure that this gets well with #715,
#11521, #14711, #15303 and other coercion related stuff, though there
should be no problems from what I currently see.
We should also to check that when the user deletes an algebraic closure
objects, everything gets garbage collected.
Maybe it needs some more thinking on the category framework integration
with more general algebraic closures (not even sure it would make sense
though)?
I see the Factory currently sets it to Fields().
Additional question: how does it interact with the AlgebraicClosureFunctor
from sage.categories.pushout?
Not sure how harmful it would be to modify that after the current ticket
is merged.
--
Ticket URL: <http://trac.sagemath.org/ticket/14990#comment:8>
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/groups/opt_out.
