Bizarre results when taking the mod of a p-adic number

[jonhanke]

The operation x % n for p-adic numbers is confusing. Added a note about it in the documentation of the 'residue' function.

CC: @williamstein @sagetrac-mabshoff @roed314

Component: padics

Keywords: mod, %

Author: Sandra Rozensztajn, Julian Rüth

Branch/Commit: a10c222

Reviewer: David Roe

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

[jonhanke]

comment:1

## Create a p-adic number in two ways
sage: e = 1 + O(2^20)  ## Explicit creation
sage: e
1 + O(2^20)
sage: c = Qp(2)(1)     ## By coercion
sage: c
1 + O(2^20)
sage: e == c
True

## Check their types
sage: type(e)
<type 'sage.rings.padics.padic_capped_relative_element.pAdicCappedRelativeElement'>
sage: type(c)
<type 'sage.rings.padics.padic_capped_relative_element.pAdicCappedRelativeElement'>

## Use the mod operation, with inconsistent results: (I expected the integer 1 in both cases)
sage: e % 8
1 + O(2^20)
sage: c % 8
0
sage: e % 8 == c % 8
False

## Check the mod types
sage: type(e % 8)
<type 'sage.rings.padics.padic_capped_relative_element.pAdicCappedRelativeElement'>
sage: type(c % 8)
<type 'sage.rings.padics.padic_capped_relative_element.pAdicCappedRelativeElement'>


## Check their lifts
sage: e.lift()
1
sage: c.lift()
1
sage: c.lift() == e.lift()
True
sage: c.lift() % 8 == e.lift() % 8
True

Suggestions:

1. x % M returns an integer when x is a p-adic number (in Qp) and M is
   an integer or raises an error if either the modulus is not a power
   of p or is larger than the known precision of the number allows.
   This syntax will return an error for any (non-trivial) extensions
   of Qp.

2. Add a more general syntax x.reduce_mod_prime() returns an element
   of FiniteField(q) whenever x is an element of an unramified
   extension Qq of Qp.

3. It might also be nice to have an x.reduce_mod_prime_power(n) which
   would return an element in the associated finite quotient ring
   Q_q/((pi)**n), but this may not be worth the effort right now.

[jonhanke]

Author: jonhanke

[roed314]

comment:3

This is a consequence of the fact that those two elements have different parents:

sage: parent(1+O(2^20))
2-adic Ring with capped relative precision 20
sage: parent(Qp(2)(1))
2-adic Field with capped relative precision 20

Most rings in sage return an element of the same ring when applying the operation %. The function you want is residue.

sage: a = Zp(2)(1); b = Qp(2)(1)
sage: a.residue(3), b.residue(3)
(1, 1)
sage: a.residue(3).parent(), b.residue(3).parent()
(Ring of integers modulo 8, Ring of integers modulo 8)
sage: c = Qp(2)(1/2)
sage: c.residue(3)
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)

ValueError: Element must have non-negative valuation in order to compute residue.

There are some tricky questions for % and // and how they relate. A similar issue bit William this past spring, so maybe we should have a design discussion about how to solve it. I'm probably not going to be working on the p-adics this fall though: my advisor wants me to work on my thesis. ;-)

[roed314]

comment:4

I was just glancing through tickets and found this one. If anyone has suggestions for making % and // less confusing, please let me know. There's documentation, but it's hidden in double underscore methods, so often doesn't get seen.

[sagetrac-rozenszt]

Branch: u/rozenszt/bizarre_results_when_taking_the_mod_of_a_p_adic_number

[sagetrac-rozenszt]

Changed author from jonhanke to Sandra Rozensztajn

[sagetrac-rozenszt]

Commit: e0cf7fe

[sagetrac-rozenszt]

New commits:

e0cf7fe

Added a note in the doc of function p-adic residue

[jdemeyer]

comment:12

Personally, I don't think that the sentence "This is different from the mod function % which returns an element with the same parent." really clarifies anything.

[jdemeyer]

comment:13

Replying to @roed314:

This is a consequence of the fact that those two elements have different parents:

Most rings in sage return an element of the same ring when applying the operation %. The function you want is residue.

There are some tricky questions for % and // and how they relate.

That may be, but it's still a poor excuse for having "bizarre" results for %. If % makes no sense, better disallow it completely.

[sagetrac-rozenszt]

comment:14

Replying to @jdemeyer:

Personally, I don't think that the sentence "This is different from the mod function % which returns an element with the same parent." really clarifies anything.

Actually there is already a detailled explanation of how the mod function works in its documentation, so the point of the note is mostly to direct people to the approriate documentation.

[saraedum]

Changed branch from u/rozenszt/bizarre_results_when_taking_the_mod_of_a_p_adic_number to u/saraedum/bizarre_results_when_taking_the_mod_of_a_p_adic_number

[sagetrac-git]

Changed commit from e0cf7fe to 7289e97

[sagetrac-git]

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

7289e97

Improved wording to distinguish _mod_() from residue() for p-adics

[saraedum]

Changed author from Sandra Rozensztajn to Sandra Rozensztajn, Julian Rüth

[sagetrac-git]

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

fadea8d

Avoid confusion in docstring of residue()

[sagetrac-git]

Changed commit from 7289e97 to fadea8d

[sagetrac-git]

Changed commit from fadea8d to a10c222

[sagetrac-git]

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

a10c222

Explain the precision loss when applying the % operator

[roed314]

Reviewer: David Roe

[roed314]

comment:20

Looks good.

[vbraun]

Changed branch from u/saraedum/bizarre_results_when_taking_the_mod_of_a_p_adic_number to a10c222