You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Documentation Decimal power 0 to the 0 is Nan (versus 0 to the 0 which is 1) #85377
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=Nonecreated_at=<Date2020-07-03.22:51:25.441>labels= ['type-feature', '3.8', '3.9', '3.10', 'docs']
title='Documentation Decimal power 0 to the 0 is Nan (versus 0 to the 0 which is 1)'updated_at=<Date2020-08-15.20:48:36.169>user='https://bugs.python.org/JD-Veiga'
I would like to propose a minor addition to decimal package documentation page (https://docs.python.org/3/library/decimal.html). I think that we should add a paragraph in context.power(x, y, modulo=None) stating that Decimal(0) ** Decimal(0) returns Decimal('NaN') instead of 1 --as 0 ** 0 does-- or 1.0 --in case of 0.0 ** 0.0.
Indeed, 0 ** 0 is NaN is mentioned as example of operations raising InvalidOperation exceptions.
However, I think that this is not enough to indicate the different behaviour of decimal versus int and float numbers.
Moreover, in the case of % and // operators, there are clear remarks on these differences (See: “There are some small differences between arithmetic on Decimal objects and arithmetic on integers and floats [...]” in the page).
Huh! I thought everyone in Standards World gave up by now, and agreed 0**0 should be 1.
JD-Veiga commented on Jul 4, 2020
JD-Veigamannequin
MannequinAuthor
More actions
Well, it is the way that it has been defined in decimal package and in the document that inspired this package (IBM's General Decimal Arithmetic Specification, The General Decimal Arithmetic Specification: http://speleotrove.com/decimal/decarith.html).
I agree that the result is surprising and should be noted in the docs; we shouldn't expect all the decimal users to be familiar with the specification. Some of the other differences with float arithmetic are noted (e.g., the behaviour of // and %), but apparently not this one. We do document the behaviour of these corner cases for math.pow.
The part that I find really odd is that the specification says that Decimal("inf")**Decimal(0) is 1. Treating one of 00 and inf0 as undefined but not the other seems inconsistent to me. We'd probably want to note the behaviour of inf**0 in the docs, too. (I tried to argue with Mike Cowlishaw about this, but I lost.)
I'm not sure whether just noting this in the "power" documentation is enough: it's not clear to me that users using the ** operator would think to check the docs for the "power" method.
The other weirdly non-IEEE 754 behaviour (again, mandated by the standard) that bugs me from time to time is that the unary - and + operators will never give negative zero: Decimal("-0.0") and -Decimal("0.0") are not the same thing. That one's probably worth noting, too.
skrah commented on Jul 4, 2020
skrahmannequin
Mannequin
More actions
Agreed, and it's even slightly worse with the ROUND_FLOOR special case:
New changeset 10e4664 by Srinivas Reddy Thatiparthy (శ్రీనివాస్ రెడ్డి తాటిపర్తి) in branch 'master': bpo-41205: Document Decimal power 0 to the 0 (GH-21386) 10e4664
Activity
JD-Veiga commentedon Jul 3, 2020
Hi,
I would like to propose a minor addition to
decimalpackage documentation page (https://docs.python.org/3/library/decimal.html). I think that we should add a paragraph incontext.power(x, y, modulo=None)stating thatDecimal(0) ** Decimal(0)returnsDecimal('NaN')instead of1--as0 ** 0does-- or1.0--in case of0.0 ** 0.0.Indeed,
0 ** 0isNaNis mentioned as example of operations raisingInvalidOperationexceptions.However, I think that this is not enough to indicate the different behaviour of decimal versus int and float numbers.
Moreover, in the case of
%and//operators, there are clear remarks on these differences (See: “There are some small differences between arithmetic on Decimal objects and arithmetic on integers and floats [...]” in the page).Thank you and sorry for the inconvenience.
tim-one commentedon Jul 4, 2020
Huh! I thought everyone in Standards World gave up by now, and agreed 0**0 should be 1.
JD-Veiga commentedon Jul 4, 2020
Well, it is the way that it has been defined in
decimalpackage and in the document that inspired this package (IBM's General Decimal Arithmetic Specification, The General Decimal Arithmetic Specification: http://speleotrove.com/decimal/decarith.html).mdickinson commentedon Jul 4, 2020
I agree that the result is surprising and should be noted in the docs; we shouldn't expect all the decimal users to be familiar with the specification. Some of the other differences with float arithmetic are noted (e.g., the behaviour of
//and%), but apparently not this one. We do document the behaviour of these corner cases formath.pow.The part that I find really odd is that the specification says that
Decimal("inf")**Decimal(0)is1. Treating one of 00 and inf0 as undefined but not the other seems inconsistent to me. We'd probably want to note the behaviour of inf**0 in the docs, too. (I tried to argue with Mike Cowlishaw about this, but I lost.)I'm not sure whether just noting this in the "power" documentation is enough: it's not clear to me that users using the ** operator would think to check the docs for the "power" method.
The other weirdly non-IEEE 754 behaviour (again, mandated by the standard) that bugs me from time to time is that the unary
-and+operators will never give negative zero: Decimal("-0.0") and -Decimal("0.0") are not the same thing. That one's probably worth noting, too.skrah commentedon Jul 4, 2020
Agreed, and it's even slightly worse with the ROUND_FLOOR special case:
That's why there are three slightly different methods for applying the
context:
context.create_decimal() ==> special case for NaN payloads.
context.apply() (private method) ==> no special cases at all.
Decimal.plus() ==> ROUND_FLOOR special case.
mdickinson commentedon Jul 7, 2020
@JD-Veiga: would you be willing to work on a PR?
skrah commentedon Jul 19, 2020
New changeset 10e4664 by Srinivas Reddy Thatiparthy (శ్రీనివాస్ రెడ్డి తాటిపర్తి) in branch 'master':
bpo-41205: Document Decimal power 0 to the 0 (GH-21386)
10e4664
miss-islington commentedon Jul 19, 2020
New changeset 8831162 by Miss Islington (bot) in branch '3.9':
bpo-41205: Document Decimal power 0 to the 0 (GH-21386)
8831162
miss-islington commentedon Jul 19, 2020
New changeset dac8a3a by Miss Islington (bot) in branch '3.8':
bpo-41205: Document Decimal power 0 to the 0 (GH-21386)
dac8a3a
skrah commentedon Aug 15, 2020
Mark, do you think that we should document the other oddity as well
or should we close this?
furkanonder commentedon May 10, 2023
@skrah Issue seems to be solved. We can close the issue.
mdickinson commentedon May 10, 2023
Closing. It doesn't seem worth documenting the
inf**0oddity unless someone yells.