#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:
-------------------------------------------------+-------------------------
Changes (by defeo):

 * cc: defeo (added)


Comment:

 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.

 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?

 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)

 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?

 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?

--
Ticket URL: <http://trac.sagemath.org/ticket/14990#comment:7>
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.

Reply via email to