Decimal 0**0

[Steven D'Aprano]

Does anyone have an explanation why Decimal 0**0 behaves so differently from
float 0**0?

Tested in both Python 2.7 and 3.3, float 0**0 returns 1, as I would expect:

py> 0.0**0.0 # floats return 1
1.0


With Decimals, if InvalidOperation is trapped it raised:

py> from decimal import getcontext, InvalidOperation
py> from decimal import Decimal as D
py> getcontext().traps[InvalidOperation] = True
py> D(0)**D(0) # Decimals raise
Traceback (most recent call last):
...
decimal.InvalidOperation: 0 ** 0


or return a NAN:

py> getcontext().traps[InvalidOperation] = False
py> D(0)**D(0)
Decimal('NaN')


I am familiar with the arguments for treating 0**0 as 0, or undefined, but
thought that except for specialist use-cases, it was standard practice for
programming languages to have 0**0 return 1. According to Wikipedia, the
IEEE 754 standard is for "pow" to return 1, although languages can define a
separate "powr" function to return a NAN.

http://en.wikipedia.org/wiki/Exponentiation#Zero_to_the_power_of_zero


I suspect this is a bug in Decimal's interpretation of the standard. Can
anyone comment?

 

[Stefan Krah]

Does anyone have an explanation why Decimal 0**0 behaves so differently from
float 0**0?

Tested in both Python 2.7 and 3.3, float 0**0 returns 1, as I would expect:

The behavior follows the specification:

http://speleotrove.com/decimal/daops.html#refpower


Why exactly the decision was made I cannot say.



Stefan Krah

 

[Steven D'Aprano]

I don't think Decimal ever promised to adhere to IEEE 754, did it?

I don't fully grok the naming specifications of the relevant standards, but
I think that, yes it did, with the understanding that 754 only defines
fixed precision arithmetic, and Decimal implement arbitrary precision.

Quoting from the decimal module's docstring:

"""
This is an implementation of decimal floating point arithmetic based on
the General Decimal Arithmetic Specification:

http://speleotrove.com/decimal/decarith.html

and IEEE standard 854-1987:

www.cs.berkeley.edu/~ejr/projects/754/private/drafts/854-1987/dir.html
"""

I'm not entirely sure what the relationship between IEEE standards 754 and
854 are, but I'm moderately confident that 754 refers only to fixed
precision and 854 refers to arbitrary precision. In any case, even if
Decimal covers *more*, it effectively promises to support IEEE 754-2008
style arithmetic.

The Berkeley link above gives "Not Found", but the decarith.html link
explains:

"""
This document defines a general purpose decimal arithmetic for both limited
precision floating-point (as defined by the IEEE 754 standard[1] approved
in June 2008) and for arbitrary precision floating-point (following the
same principles as IEEE 754 and the earlier IEEE 854-1987 standard).
"""


In this case, I think the Wikipedia article has got it wrong, or at least
that its claim requires evidence. I see no evidence that IEEE 754-2008
defines "pow" to return 1, with "powr" to return NAN. But even if it does,
in this case the "general purpose decimal arithmetic" wins, and it defines
only a single power function:

http://speleotrove.com/decimal/daops.html#refpower

"If both operands are zero ... the result is [0,qNaN]"

so the behaviour of the Decimal module matches the specification. (I think
the spec is wrong to mandate NAN, and I think that what Wikipedia says is a
sensible way to do it, but it's not what the standard mandates.)

The spec also allows for a *subset* of the full behaviour, ANSII X3.274,
where power(0, 0) returns 1. But that's not what Decimal promises, and
supporting X3.274 as well as the general decimal specification would be a
big job.