#8335: Finite Field lattices for (pseudo-)Conway polynomials
------------------------------------------------+---------------------------
Reporter: roed | Owner: AlexGhitza
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-5.11
Component: algebra | Resolution:
Keywords: days49 | Work issues:
Report Upstream: N/A | Reviewers: Jean-Pierre
Flori, Luca De Feo
Authors: David Roe, Jean-Pierre Flori | Merged in:
Dependencies: #13894 | Stopgaps:
------------------------------------------------+---------------------------
Comment (by jpflori):
Replying to [comment:71 pbruin]:
> In relation to #12142, I am currently working on a patch that makes the
construction of irreducible polynomials independent of the finite field
implementations (prime_modn, givaro, ntl_gf2e, ext_pari and the future
pari_ffelt). Currently every finite field implementation has to do its
own parsing of string values of modulus (like 'conway', 'random' etc.).
It would be more elegant to handle all these string values in the generic
constructor, and always pass an actual polynomial to the finite field
implementation.
>
> In the current version of Sage, the only situation in which the
implementation needs to know whether the field is defined by a Conway
polynomial is when converting elements to GAP. This means that always
passing a polynomial as the modulus is fine, as long as one can check if
the polynomial is a Conway polynomial if and when it is needed. This is
easy to do by checking the database.
Beware that the last patch which contains my modification to the two
original patches by David changes quite a lot of thing.
In particular, I think that with it modulus contains the real modulus as
well and I use additional attributes to check for pseudo-Conway
construction.
Also note that the real nice addition of this patch is mainly the
compatible embeddings.
Indeed, for practical purposes, it seems that only the Conway polynomials
from the databse will be used.
Constructing pseudo-Conway polynomials is quite as slow as contructions
genuine Conway polynomials so when you will actually use them, i.e. for
quite large parameters because you have to be outside of the Conway
database, it will already be quite slow and unpractical.
>
> With your patch, each implementation gets an increased dependence on
string values for the modulus parameter. I am wondering if this can be
avoided by doing all the pseudo-Conway related stuff inside the generic
finite field code.
>
> [...to be continued...]
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/8335#comment:72>
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.
