Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

function fields over towers of finite fields don't work #103

Open
3 of 4 tasks
swewers opened this issue Aug 20, 2018 · 15 comments
Open
3 of 4 tasks

function fields over towers of finite fields don't work #103

swewers opened this issue Aug 20, 2018 · 15 comments
Labels
bug Something isn't working upstream: reported An issue that originates in Sage, a trac ticket has been created the fix is not ready yet

Comments

@swewers
Copy link
Contributor

swewers commented Aug 20, 2018

The following gives an error:

sage: R0.<z> = GF(2)[]
sage: k1 = GF(2).extension(z^2+z+1, 'z1')
sage: R1.<z> = k1[]
sage: k2 = k1.extension(z^2+z+k1.gen(), 'z2')
sage: k2
Univariate Quotient Polynomial Ring in z2 over Finite Field in z1 of size 2^2 with modulus z2^2 + z2 +z1
sage: F.<x> = FunctionField(k2)
sage: F.derivation()

NotImplementedError                       Traceback (most recent call last)

The problem is that k2, although a finite field, is not constructed as a 'true' finite field, and k2.is_perfect() is not implemented (and there are probably many more problems with
function fields over such a field).

However, fields as k2 occur frequently as residue fields of valuations, and there seems to be no easy way to construct an isomorphism from k2 to an isomorphic 'true' finite field.

TODO:

@swewers
Copy link
Contributor Author

swewers commented Aug 20, 2018

This is related to issue #66, in that the residue field of a valuation should have the 'natural type', e.g. a function field over a 'true' finite field.

@swewers
Copy link
Contributor Author

swewers commented Aug 20, 2018

Another problem is that factoring of polynomials over towers of fields is rediculously slow.

@swewers swewers added bug Something isn't working help wanted Extra attention is needed labels Aug 20, 2018
@swewers
Copy link
Contributor Author

swewers commented Aug 20, 2018

I was not able to construct a homomorphism from k2 into an isomorphic finite field. The problem is that although k2 is a quotient of a polynomial ring, k2.cover() is not implemented, and this seems to make
it impossible to construct a morphism from k2 to another ring which is not a coercion on the base ring of k2.

@swewers
Copy link
Contributor Author

swewers commented Aug 20, 2018

It seems that Sage can be fooled by setting check=False when defining a homomorphism on k2, induced from a homomorphism on k2.cover_ring():

def make_finite_field(k):
     r""" Return the finite field isomorphic to this field.

     INPUT:

     - ``k`` -- a finite field

     OUTPUT: a pair `(k_1,\phi)` where `k_1` is a 'true' finite field
     and `\phi` is an isomorphism from `k` to `k_1`.

    This function is useful when `k` is constructed as a tower of extensions
    with a finite field as a base field.

    """
    from sage.categories.finite_fields import FiniteFields

    assert k.is_field()
    assert k.is_finite()
    if k in FiniteFields:
        return k, k.hom(k.gen(), k)
    else:
        k0 = k.base_field()
        G = k.modulus()
        assert G.parent().base_ring() is k0
        k0_new, phi0 = make_finite_field(k0)
        G_new = G.map_coefficients(phi0, k0_new)
        k_new = k0_new.extension(G_new.degree())
        alpha = G_new.roots(k_new)[0][0]
        Pk0 = k.cover_ring()
        Pk0_new = k0_new[Pk0.variable_name()]
        psi1 = Pk0.hom(phi0, Pk0_new)
        psi2 = Pk0_new.hom(alpha, k_new)
        psi = psi1.post_compose(psi2)
        # psi: Pk0 --> k_new
        phi = k.hom(Pk0.gen(), Pk0, check=False)
        phi = phi.post_compose(psi)
        return k_new, phi

@swewers
Copy link
Contributor Author

swewers commented Aug 20, 2018

Defining a homomorphism on the fraction field of a polynomial ring doesn't work as expected:

sage: l = GF(3)
sage: k0 = PolynomialRing(l, 'x').fraction_field()
sage: k1 = FunctionField(l, 'x')
sage: phi = k0.hom(k1.gen(), k1)
sage: phi
Ring morphism:
  From: Fraction Field of Univariate Polynomial Ring in x over Finite Field of size 3
  To:   Rational function field in x over Finite Field of size 3
  Defn: x |--> x
sage: phi(k0.gen())

NotImplementedError                       Traceback (most recent call last)
...
NotImplementedError: 

swewers added a commit to swewers/mclf that referenced this issue Aug 20, 2018
This tries to fix the problems 
described in issue MCLF#103.

The code is very experimental..
@saraedum
Copy link
Member

I am also having a look at this now.

@saraedum
Copy link
Member

Do I understand correctly that solving #66 would solve this?

@swewers
Copy link
Contributor Author

swewers commented Aug 20, 2018

Hopefully, yes, but we would have to make it more precise what a solution of #66 would mean.

@saraedum
Copy link
Member

saraedum commented Aug 20, 2018

Ok. I mean, all the finite fields you are having trouble with are residue fields of valuations? Or are you also creating iterated extensions yourself?

@saraedum
Copy link
Member

So one thing we'd need would be a simple_model(base=None) on polynomial quotient rings that returns the polynomial ring as a simple extension of base (where base defaults to the prime subfield) together with isomorphisms.

@saraedum
Copy link
Member

saraedum commented Aug 20, 2018

I created https://trac.sagemath.org/ticket/26103 for this. I hope that I'll find some time to work on it tomorrow.

@swewers
Copy link
Contributor Author

swewers commented Aug 21, 2018

Ok. I mean, all the finite fields you are having trouble with are residue fields of valuations? Or are you also creating iterated extensions yourself?

I try to use k.extension(n) which creates another finite fields with card(k)^n elements. It seems that there is a natural embedding of k into this extension:

sage: k0 = GF(2)
sage: k1 = k0.extension(2)
sage: k1
Finite Field in z2 of size 2^2
sage: k1.has_coerce_map_from(k0)
True
sage: k2 = k1.extension(3)
sage: k2
Finite Field in z6 of size 2^6
sage: k2.has_coerce_map_from(k1)
True
sage: k3 = k0.extension(3)
sage: k2.has_coerce_map_from(k3)
True

So for 'true' finite fields, it is assumed that are all embedded into one algebraic closure of FF_p. That is fine, IMO. If one wants to have specific embeddings (which may be the case), you can do this yourself.
However, once k is not a true finite field anymore, k.embedding(n) doesn't work anymore, and one has to create another explicit simple extension on top of k.

An example where I had to do this is in the branch fix_urgent_bug, in smooth_projective_curves.py, line 1208-1214.

@swewers
Copy link
Contributor Author

swewers commented Aug 21, 2018

So one thing we'd need would be a simple_model(base=None) on polynomial quotient rings that returns the polynomial ring as a simple extension of base (where base defaults to the prime subfield) together with isomorphisms.

Wouldn't it be enough if k.extension(f) created an extension field, together with an underlying absolute finite field, just like for number fields?

@saraedum
Copy link
Member

Yes but that's harder to do I think. There is sage.coding.relative_finite_field_extension which I just found out about. And there were several attempts to create relative fields, e.g., https://trac.sagemath.org/ticket/23316.

@swewers
Copy link
Contributor Author

swewers commented Aug 21, 2018

Actually, for me simple_model(k, base=None) would be enough. That's approximately what I was trying to do with make_finite_field (see comment above).

swewers added a commit to swewers/mclf that referenced this issue Aug 21, 2018
there is now a new version of 
`make_finite_field` and `make_function_field`,
which is a hack to solve issue MCLF#103. Adaptions
to this in several places. 

It may be an option to keep these two functions
in an experimental version until https://trac.sagemath.org/ticket/26103 
is completed.
However, the whole module `reduction_trees` needs to 
be reviewed first.
swewers added a commit to swewers/mclf that referenced this issue Aug 22, 2018
In this new version of reduction_trees, 
the maps between different components
(inertial, lower and upper) are constructed
in a systematic way and such that they are 
compatible with the maps of generic fibers.

All components are created as curves over an
*absolute* finite fields, thus fixing issue MCLF#103
and adressing in aprt issue MCLF#66. This is done
by using the helper functions and  
`make_finite_fields` which turns a finite field into an absolute fielte, 
and `make_function_fields`
which turns a function field into a 'true' function
field over an absolute finite field. 

There should be more doctests and internal 
consistency test.
swewers added a commit that referenced this issue Aug 24, 2018
This merge fixes several bugs and started a reorganization of `reduction_trees`

The key commit is 8844501:

In this new version of reduction_trees, 
the maps between different components
(inertial, lower and upper) are constructed
in a systematic way and such that they are 
compatible with the maps of generic fibers.

All components are created as curves over an
*absolute* finite fields, thus fixing issue #103
and adressing in part issue #66. This is done
by using the helper functions and  
`make_finite_fields` which turns a finite field into an absolute fielte, 
and `make_function_fields`
which turns a function field into a 'true' function
field over an absolute finite field. Once `trac:26103` is merged,
these functions can probably be removed. 

I think a further reorganization of `reduction_trees` and, related
to this, of `smooth_projective_curves` and `morphisms_of_smooth_projective_curves`
is necessary, but this will do for a while.
@saraedum saraedum added upstream: reported An issue that originates in Sage, a trac ticket has been created the fix is not ready yet upstream: needs review A fix has been submitted to Sage and is pending review labels Aug 29, 2018
@saraedum saraedum removed help wanted Extra attention is needed upstream: needs review A fix has been submitted to Sage and is pending review labels Nov 21, 2018
@saraedum saraedum added the upstream: needs review A fix has been submitted to Sage and is pending review label Dec 20, 2018
swewers added a commit that referenced this issue Feb 18, 2019
With Sage 8.6, residue fields of valuations on function fields are now 
function fields themselve, if this makes sense. However, the constant 
base field may not be a *true* finite field (this is trac:26103). This 
resulted in an error message when applying the method 
``make_function_field``.

Now ``make_function_field`` creates a new function field with the right 
kind of constant base field if the input is already a function field.
swewers added a commit that referenced this issue Feb 18, 2019
Fix bug related to issue #103
@saraedum saraedum removed the upstream: needs review A fix has been submitted to Sage and is pending review label Feb 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working upstream: reported An issue that originates in Sage, a trac ticket has been created the fix is not ready yet
Projects
None yet
Development

No branches or pull requests

2 participants