#13214: Frobenius endomorphism over finite fields
-------------------------------------------+--------------------------------
Reporter: caruso | Owner: AlexGhitza
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-5.11
Component: basic arithmetic | Resolution:
Keywords: frobenius finite fields | Work issues: does not build
Report Upstream: N/A | Reviewers: Paul Zimmermann
Authors: Xavier Caruso | Merged in:
Dependencies: #13184 | Stopgaps:
-------------------------------------------+--------------------------------
Comment (by pbruin):
Replying to [comment:27 jpflori]:
> Which is basically what we currently have and also what this ticket
does.
Yes, and precisely for this reason I think it is important to have a clear
picture of what belongs in the "category of all finite fields" framework,
what belongs in the future "finite subfields of a given algebraic closure"
framework, and what is independent of the framework. Among the category-
independent things would certainly be the various classes implementing the
interfaces to FLINT, Givaro, NTL and PARI, and to a large extent the
`FiniteField` base class itself.
> > - the category of finite subfields of a given algebraic closure of
'''F''',,''p'',,. In this category there is at most one morphism beteen
any two objects, namely the inclusion qua subfields of the given algebraic
closure.
> I would like this to be the default at some point, just like in Magma,
not because I want to replicate Magma but for usual computations it seems
a more practical choice.
That probably depends strongly on the application. Often one just needs
to work with a single finite field. In such cases it would be nicer if
creating this field would give you a sparse polynomial for efficiency, not
one that has been constructed to fit in an algebraic closure that you are
unlikely to use.
Of course it would be best if one could do both at the same time, like
Magma (see references at #8751), by having an implementation that allows
using sparse polynomials while still being able to put the fields in a
compatible system/algebraic closure. However, that should probably be
done on top of the distinction between the two categories mentioned above,
not by muddling this distinction.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13214#comment:28>
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.
