#15236: Let Sage use finite fields without primality proving
-------------------------------------------------+-------------------------
Reporter: jpflori | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: sage-6.0
Component: finite rings | Resolution:
Keywords: finite fields, primality | Merged in:
proving | Reviewers:
Authors: | Work issues:
Report Upstream: N/A | Commit:
Branch: | Stopgaps:
Dependencies: |
-------------------------------------------------+-------------------------
Changes (by jpflori):
* cc: burcin (added)
Old description:
> It would be nice to be able to create finite fields without checking that
> the characteristic is actually prime.
>
> You can more or less do that for prime fields using directly the
> FiniteField_prime_modn constructor with check=False arguments.
> Unfortunately some constructions on top of this will still check that the
> characteristic is actually prime, e.g. univariate polynomial rings on top
> of it.
>
> Note that it already is possible to create an `IntegerModRing(n,
> categogry=Fields())`. This will create a quotient ring of ZZ that
> believes that it is a field. However, it will still be an integer mod
> ring that does not use any of the fancy finite ''field'' implementations
> in sage.
New description:
It would be nice to be able to create finite fields without checking that
the characteristic is actually prime.
You can more or less do that for prime fields using directly the
FiniteField_prime_modn constructor with check=False arguments.
Unfortunately some constructions on top of this will still check that the
characteristic is actually prime, e.g. univariate polynomial rings on top
of it.
Note that it already is possible to create an `IntegerModRing(n,
categogry=Fields())`. This will create a quotient ring of ZZ that believes
that it is a field. However, it will still be an integer mod ring that
does not use any of the fancy finite ''field'' implementations in sage
(and you'll have problems similar to those with the FiniteField_prime_modn
anyway).
--
Comment:
I think this ticket might also be a good place to think about the use of
methods like x.is_field(), x.is_prime_field(), x.is_finite_field(),
x.is_integral_domain() and the constructions provided by the category
framework like x in Fields(), x in FiniteFields(), x in IntegralDomains(),
and so on.
Is there a real speed penalty when using the second construction
(especially when x is actually not in Fields(), FiniteFields and so on as
Simon suggested)?
Does this speed penalty actually make some code awfully slow (maybe in
elliptic curves computations as Simon suggested)?
Are there places where we really depend on the actual implementation used
and so where using is_FiniteField(x) and similar stuff cannot be replaced
by x.is_finite_field() or x in FiniteFields() anyway?
--
Ticket URL: <http://trac.sagemath.org/ticket/15236#comment:2>
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.
