Fraction field of fixed modulus p-adic rings should have floating point type

[Brian Sinclair]

Fraction field of fixed modulus p-adic rings should have floating point type.

Currently the change() method requires that the type be specified, in this case, but instances such as the check R.fraction_field() is self occurring in _coerce_map_from_(self, R) in padic_extension_generic.pyc.

[David Roe]

Last 10 new commits:

​921af5e	Changing modulus and defining_polynomial to use an exact keyword
​39043f1	Merge branch 't/23331/allow_exact_defining_polynomials_for_p_adic_extensions' into t/20310/change_precision
​77779ea	minor docstring changes
​6e2495f	Merge branch 't/23331/allow_exact_defining_polynomials_for_p_adic_extensions' into t/20310/change_precision
​7428353	minor docstring fixes
​bd15d71	add exact keyword
​99dccf6	Merge branch 't/23331/allow_exact_defining_polynomials_for_p_adic_extensions' into t/20310/change_precision
​ef4ed33	Fix SEEALSO:
​1754b44	Fix exact=True errors in the right branch
​7926b41	Moving code for fraction_field and integer_ring, and enabling fraction fields for fixed-mod

[Adèle Bourgeois]

All tests pass!

[Julian Rüth]

sage: R.<u> = ZqFM(125, 500)
sage: R.fraction_field().coerce_map_from(R)
UnboundLocalError: local variable 'coerce_map' referenced before assignment

[Xavier Caruso]

By the way, I would be in favour of implementing a p-adic field with fixed modulus precision (in which each p-adic number is truncated at the same precision encapsulated in the parent). I think it makes perfectly sense. Do you have any objections?

---

New commits:

​16fb79b

Check that fraction_field() works as expected

[David Roe]

Replying to caruso:

By the way, I would be in favour of implementing a p-adic field with fixed modulus precision (in which each p-adic number is truncated at the same precision encapsulated in the parent). I think it makes perfectly sense. Do you have any objections?

So, the amount of information stored in an element is unbounded. This seems problematic since computations can blow up. Why do you want to have this precision type?

[Xavier Caruso]

Replying to roed:

So, the amount of information stored in an element is unbounded. This seems problematic since computations can blow up.

Indeed. But is it really an issue? I noticed that similarly QpCA does not exist and that the fraction field of ZpCA is QpCR and I assume that this is for the same reason, isn't it?

Why do you want to have this precision type?

I will maybe need it for implementing precision lattices for which I imagine an absolute cap (having a relative cap is certainly also interesting but does not solve the issue of unbounded elements in the framework of lattice precision since the precision may be spread out over several elements which have quite different valuations).

However, besides this, I think that QpCA and QpFM make sense perfectly and should be the integer ring of ZpCA and ZpFM respectively. I don't think that it is a good idea to switch automatically between absolute and relative precision, it should be the choice of the user. For instance, for now, we have the following behaviour

    sage: R = ZpCA(5)
    sage: R.fraction_field().integer_ring()
    5-adic Ring with capped relative precision 20
    sage: R.fraction_field().integer_ring() is R
    False

which is, I think, a bit annoying.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​8814d31

Merge branch 'develop' into t/23510/fixed_mod_frac_field

[David Roe]

Depend on #14825 to include fixes for sections that are internal to coercion system. Tests pass.

As for the discussion about adding QpFM and QpCA, I don't have a strong objection, but it will be very difficult to implement with the current framework in Sage. In particular, it would require two new templates, since the CR_template and FP_template don't have the correct precision behavior, while the CA_template and FM_template don't have the right data representation (they can't store elements with negative valuation). I don't think this is going to happen anytime soon.

---

Last 10 new commits:

​7f87069	Fix segfault
​b9c2fe4	Fix pickling of sections for p-adic coercions
​6ba62dd	Fix SEEALSO again
​e9c4c39	Merge branch 'u/roed/allow_exact_defining_polynomials_for_p_adic_extensions' of git://trac.sagemath.org/sage into t/23331/allow_exact_defining_polynomials_for_p_adic_extensions
​561f5ac	Fix doctest errors
​3142701	Merge branch 'u/roed/change_precision' of git://trac.sagemath.org/sage into t/20310/change_precision
​138d939	Fix string representation doctest from #22103
​1eeb367	Merge branch 't/20310/change_precision' into t/14825/polynomial_representation_of_a_padic_number
​bc95b69	Merge branch 't/14825/polynomial_representation_of_a_padic_number' into t/23510/fixed_mod_frac_field
​7e62f70	Fixing errors in the coercion to the fraction field for fixed-mod p-adics

[David Roe]

Diff against #14825 for ease of review

[git]

Branch pushed to git repo; I updated commit sha1. Last 10 new commits:

​2d87353	Merge branch 'develop' into t/13591/ticket/13591
​9cd2d5d	Fixup the preceding merge.
​5d7dbb9	Merge branch 'develop' into t/13591/ticket/13591
​58c7ae6	Merge branch 'u/saraedum/ticket/13591' of git://trac.sagemath.org/sage into t/13591/add_bigoh
​782df2e	Fix prec_cap -> ram_prec_cap
​1a4333a	Merge branch 't/13591/add_bigoh' into t/23510/fixed_mod_frac_field
​538b48c	Fixing problems revealed by doctests
​cdeb376	Merge branch 't/13591/add_bigoh' into t/23510/fixed_mod_frac_field
​cb882fd	Update add_bigoh to account for fixed-mod having a fraction field
​b9c3a23	Fix _tester_add_bigoh

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​a826978

Fix _tester_add_bigoh

[David Roe]

Diff against #14825 and #13591 for ease of review

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​883e6b5

Fix doctest in local_generic_element.pyx

[git]

Branch pushed to git repo; I updated commit sha1. Last 10 new commits:

​1bb288f	protect LaTeX commands
​054e5d6	clarify where _list_zero comes from
​0b7fd02	default docstring layout
​def3897	replace p with pi and clarify meaning of expansion
​99c40d6	add unit test for expansion
​6732d38	coefficients might be lists in the maximal unramified subextension
​acc606a	Merge branch 'u/saraedum/polynomial_representation_of_a_padic_number' of git://trac.sagemath.org/sage into t/14825/polynomial_representation_of_a_padic_number
​40737f6	Fix some of the errors in _test_expansion
​6efed0b	Merge branch 'u/roed/polynomial_representation_of_a_padic_number' of git://trac.sagemath.org/sage into t/14825/polynomial_representation_of_a_padic_number
​52cbd2a	Merge branch 'u/roed/fixed_mod_frac_field' of git://trac.sagemath.org/sage into t/23510/fixed_mod_frac_field

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​fee575d	Merge branch 't/14825/polynomial_representation_of_a_padic_number' into t/23510/fixed_mod_frac_field
​3292259	Merge branch 'u/saraedum/fixed_mod_frac_field' of git://trac.sagemath.org/sage into t/23510/fixed_mod_frac_field

[Volker Braun]

See patchbot

[David Roe]

Thanks. Setting back to needs review for tests...

---

New commits:

​b81b722	Remove use of depraceted list()
​04a1579	Fix NOTES blocks
​6764ea2	Merge branch 'develop' into t/14825/polynomial_representation_of_a_padic_number
​dad02c7	Merge branch 'u/saraedum/fixed_mod_frac_field' of git://trac.sagemath.org/sage into t/23510/fixed_mod_frac_field
​189ac2b	Add _test_fraction_field to the coercion tutorial

[David Roe]

The test failures don't seem to be related to this ticket....

[Julian Rüth]

This does not fix the following problem:

sage: R=ZpFM(3)
sage: K=R.fraction_field()
sage: K.coerce_map_from(R).is_injective()
NotImplementedError

[Julian Rüth]

Let's make this a new issue, #23965.