Enhancing function field capabilities: collapse a tower of function field extensions to a simple extension and more

[saraedum]

The aim of this ticket is changed to merge Julian's function field personal codes into function field package which includes the initial purpose of the ticket:

• Implement a method absolute_field() for function fields, i.e., collapse a tower of separable extensions to one simple extension.

and

• primitive_element: compute a primitive element of the function field over base.

• change_generators: changing the base rational function field over which the function field is defined.

• inversion for function field homomorphisms

Depends on #9054

CC: @sagetrac-sydahmad @koffie @mminzlaff

Component: commutative algebra

Keywords: function fields

Reviewer: Julian Rueth

Issue created by migration from https://trac.sagemath.org/ticket/12194

[sagetrac-sydahmad]

All functions are included and passes the sage -t but need more work

[sagetrac-sydahmad]

comment:2

Attachment: trac_12194_julian_func_field_enhancements.patch.gz

I know this still incomplete and at least needs more testing and more complete documentation besides housekeeping and other stuff. But I uploaded it, so I can have some inputs from people before taking further steps. The current codes passes all the tests but I had to apply quite few changes to it. Many of them, I think were routine but I would like to share some other one that I'm not sure was ok:

1. The check for validity of construction of FunctionField_polymod has been entirely moved to its constructor, as a result one can not check for the stuff like this:

sage: kx.<x> = FunctionField(FiniteField(5))
sage: kz.<z> = FunctionField(FiniteField(7))
sage: kzY.<Y> = kz[]
sage: kxy.<y> = kx.extension(Y^2 - z^3 -1)
sage: kxy.base_field() == kx
False
sage: kxy.base_field() == kz
True

So I had to put the code for preventing above situation in "extension" function.

2. Apparently (polynomial) generator functions do not accept lists of variables anymore raising "not hashable" error, so I changed all calls to these functions from names=[name] to names=(name). However the functions in the patches still accepts the variables in list, but I think we should change those as well.

3. Few test examples were failing due to the strange reason that the example line had comments: like this

K.<x> = FunctionField(QQ) #optional x

I couldn't figure out what is the real cause so I just ommited these comments to pass the tests.

4. In some cases the code computes different result from examples expectations, but in those cases, I found that the expectaion doesn't make much of sense. For example we have:

(Function field in y defined by -y^4 + x, Morphism of function fields defined by y^4 |--> x,  y |--> y, Morphism of function fields defined by y |--> y,  x |--> y^4)

But, I think a morphisim should take a generator to somewhere, not a power of it as in y!^4 |--> x. In these cases, I check the result of the code in Magma and it seemed to be correct (the field where isomorphics and the computed isomorphism was one of the possible isomorphism).

5. There was confusion in order of isomorphisms which was stopping the code from working at the beginning. All functions were returning the From_self_to_simpleField first then its inverse, except for the make_simple. So, I changed the order of return vars in make_simple and everthing seems to work fine.

That is for now and happy new year!

[sagetrac-sydahmad]

comment:3

And one more thing:

6. There was no function to compute the inverse of morphisms with RationalFunctionField domain, so I cooked one using the inversion of morphisims with FunctionField_polymod domain, but I think we can probably do better.

[sagetrac-sydahmad]

comment:4

I think I  found a bug in change_generators(t,w) , I think if t isn't integral over k[x], it doesn't work properly. I think we need to multiply the elements of [t!^e*w!d] matrix with the lcm of their denominators and that's enough for a cure. In few cases, that I checked I got the correct result.

Also, I don't understand how do we know that dimension of the kernel of the above matrix is always one. Doesn't it mean that we should know the dimension of the Riemman-Roch space generated by the by poles of t and w with some multiplicity? Is it easy to be computed? If it's that easy, can't we use it to compute the genus?

[saraedum]

comment:8

This is now superseded by #16518, #16530, #16561, #16562, #16563, #16564, #16565, #16572, #16575, #16576.

[saraedum]

Reviewer: Julian Rueth