#31875 closed defect (fixed)

Exponentiation of p-adics fails when exponent is exact zero

Reported by: Peter Bruin Owned by:
Priority: major Milestone: sage-9.4
Component: padics Keywords: pow, zero
Cc: Samuel Lelièvre Merged in:
Authors: Peter Bruin Reviewers: Travis Scrimshaw
Report Upstream: N/A Work issues:
Branch: dbaface (Commits, GitHub, GitLab) Commit: dbaface15f586e947680c1008fc72559273e441f
Dependencies: Stopgaps:

Status badges

Description

In SageMath 9.3:

sage: R = Zp(2)
sage: R(1)^R(0)
Traceback (most recent call last):
...
MemoryError: failed to allocate 576460752303423520 bytes

sage: R.<a> = Zq(4)
sage: R(1)^R(0)
sig_error() without sig_on()
(crash)

Change History (10)

comment:1 Changed 17 months ago by Peter Bruin

Summary: Exponentation of p-adics fails when exponent is inexact zeroExponentiation of p-adics fails when exponent is exact zero

comment:2 Changed 16 months ago by Samuel Lelièvre

Cc: Samuel Lelièvre added
Keywords: pow zero added

Exponentiation with a zero exponent should return the ambient ring's "one" element.

comment:3 in reply to:  2 Changed 16 months ago by Peter Bruin

Replying to slelievre:

Exponentiation with a zero exponent should return the ambient ring's "one" element.

Indeed. This 1 could either have the default precision of the ring or the precision of x in the x^(exact 0) being computed. The first option seems the most logical to me since x^(exact 0) is 1 independently of (the precision of) x.

comment:4 Changed 16 months ago by Peter Bruin

Authors: Peter Bruin
Branch: u/pbruin/31875-padic_exponentiation
Commit: dbaface15f586e947680c1008fc72559273e441f
Status: newneeds_review

Note: FM_template.pxi has a completely different implementation of __pow__() (only for integer exponents) than the three files modified by this branch. We leave this file unchanged.

comment:5 Changed 16 months ago by Travis Scrimshaw

Reviewers: Travis Scrimshaw

I think the first option is the most sensible. Now there is another issue of 0^0:

sage: R = ZpCA(19, 5, print_mode='series')
sage: R(0)^R(0)
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-4-4a773a9fb9d4> in <module>
----> 1 R(Integer(0))**R(Integer(0))

~/sage-build/local/lib/python3.9/site-packages/sage/rings/padics/CA_template.pxi in ...
    503             else:
    504                 if not exact_exp and self.absprec > 0:
--> 505                     raise ValueError("in order to raise to a p-adic exponent, base must be a unit")
    506                 raise PrecisionError("Need more precision")
    507         else:

ValueError: in order to raise to a p-adic exponent, base must be a unit

To match Sage/Python, this should also return 1. I also think 0 should be special-cased in the exponentiation as R(0)^R(1) also fails.

I am okay with letting this ticket go as-in, but I think it would be better to fix this other issue here.

comment:6 Changed 16 months ago by Peter Bruin

I think 0^a should only be 0 if a is an exact zero, not if a is an inexact zero. For example, 0^(p^100) should be 0 for compatibility with the integers.

This already works (with the current patch) in capped relative precision:

sage: R = Zp(2)
sage: R(0)^R(0)
1 + O(2^20)
sage: R(0)^(O(2^20))
Traceback (most recent call last):
...
ValueError: in order to raise to a p-adic exponent, base must be a unit

The reason R(0)^R(0) fails in your example (and should fail, in my opinion) is that exact zero does not exist when working in capped absolute precision.

comment:7 in reply to:  5 Changed 16 months ago by Peter Bruin

Replying to tscrim:

I also think 0 should be special-cased in the exponentiation as R(0)^R(1) also fails.

Things like R(0)^(inexact element) are not well defined; for example, there is no way of knowing whether x^(1 + O(p^n)) should mean x^1 (i.e. x) or something else like x^(1 - p^n), which is in general completely different (or even undefined if x = 0). I prefer to just fix the bug and not change anything else.

comment:8 Changed 16 months ago by Travis Scrimshaw

Status: needs_reviewpositive_review

Okay, thank you for the explanations. Positive review.

comment:9 Changed 16 months ago by Samuel Lelièvre

Another powering ticket needs review at #11323.

comment:10 Changed 16 months ago by Volker Braun

Branch: u/pbruin/31875-padic_exponentiationdbaface15f586e947680c1008fc72559273e441f
Resolution: fixed
Status: positive_reviewclosed
Note: See TracTickets for help on using tickets.