>>> import decimal
>>> x = 0
>>> y = float(x)
>>> z = decimal.Decimal(x)
>>> x == y == z == x
True
>>> x ** x
1
>>> y**y
1.0
>>> z**z
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/decimal.py", line 2216, in __pow__
    return context._raise_error(InvalidOperation, '0 ** 0')
  File "/usr/lib/python2.7/decimal.py", line 3872, in _raise_error
    raise error(explanation)
decimal.InvalidOperation: 0 ** 0

This is PHP-like and confusing, and maybe not justified just by standards compliance. If it is justified by standards compliance, this deserves to be spelled out in big red letters in the documentation for the decimal module, along with any other inconsistencies.

In the code there is this comment:
    # 0**0 = NaN (!), x**0 = 1 for nonzero x (including +/-Infinity)
and raising the error for this specific case seems intentional.

Intentional, but really hard to justify from a consistency perspective. There appear to be several reasonable arguments to treat it as 1 regardless of the mathematical impurity ( https://www.math.hmc.edu/funfacts/ffiles/10005.3-5.shtml ), and since we clearly accept that for int and float, it seems reasonable to extend it to Decimal.

Yes, also, it is documented: https://docs.python.org/3/library/decimal.html#decimal.InvalidOperation

Still, the status quo is bad. At the very least there should be clear documentation on how Decimal differs in behavior from floats and ints. (Other than the obvious, like 1/5 taking on a different value -- although explicitly mentioning that in the list might be a good idea.)

BTW, 0**0=1 is not mathematically impure. It at one point was fairly well accepted as the right answer, since it's the one that tends to come out naturally . e.g. http://arxiv.org/abs/math/9205211 page 6 ("ripples") . This might explain why ints and floats so casually evaluate 0**0 to 1.

This behavior seems to be required by the General Decimal Arithmetic
Specification (http://speleotrove.com/decimal/daexcep.html ):

> The following exceptional conditions can occur:
>     [...]
>     Invalid operation
>         This occurs and signals "invalid-operation" if:
>             [...]
>             * both operands of the "power" operation are zero

"signals invalid-operation" apparently being mapped by default in Python to "raise the InvalidOperation exception".

> this deserves to be spelled out in big red letters in 
> the documentation for the decimal module, along with 
> any other inconsistencies.

I think you lost all sense of proportion here.  The decimal module is obliged to follow the decimal spec (that is its reason for existence).

The decimal module docs are already create a heavy mental load and their usability would not be improved shifting focus to corner case inconsistencies between types that haven't proven to be an issue in practice.  If you were to go write a blog post about 0**0 versus Decimal(0)**0, I think you would find that no one cares.

> This behavior seems to be required by the General Decimal Arithmetic
Specification (http://speleotrove.com/decimal/daexcep.html )

Yes, exactly.  The decimal module strictly follows that specification.  I don't like the 0**0 -> NaN result much either (especially when we also have inf**0 -> 1), but it's what's specified.  I've talked to Mike Cowlishaw (the author of the specification) about this particular issue, and the spec is not likely to change on this point.

> the spec is not likely to change on this point.

In this case, we should just document the behaviour with a reference to the General Decimal Arithmetic Specification.

The docs already reference the spec.

Does the spec have a handy list of differences to floats anywhere, or do you have to internalize the whole thing?

The behavior is already documented (power function):

  "at least one of x or y must be nonzero"


The decimal docs are already so large that it is probably a bad
idea to add a warning.

Mark Dickson wrote:
> I've talked to Mike Cowlishaw (the author of the specification)
> about this particular issue, and the spec is not likely to 
> change on this point.

I'm curious about the rationale for the decision. As I'm sure you're aware, in general 0**0 is treated as 1 by both a majority (I think) of mathematicians and programming languages. As Knuth puts it, the binomial theorem is too important to do otherwise. IEEE 754 treats it as 1, although the 2008 revision adds a second power function powr() which returns NAN if both arguments are 0. So I wonder why the decimal spec choose to do otherwise?

(Not saying they're wrong to do so.)

This is easy:  Cowlishaw is wrong on this one, but nothing can be done about it ;-)

Confusion arises because most people think of 0**0 as a value (where it certainly must be 1) while others seem to view it as some kind of shorthand for expressing a limit (as the base and/or exponent _approach_ 0, in which case there is no correct answer - it's an "indeterminate form").

It's in the "spirit of 754" to take inputs at face value, viewing them as infinitely precise.  So viewing 0**0 as anything other than 1 in this context is perverse.

Centuries of history distilled to a few paragraphs here:

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

Thank you Tim.

A possibility would be to add "(disallowed by the Decimal standard)" to the exception message.

> A possibility would be to add "(disallowed by the 
> Decimal standard)" to the exception message.

That is what InvalidOperation means ;-)

For the differences between the standard and IEEE 754-2008 we could
link to:

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


In the long run, perhaps we should move to IEEE, because we're
almost there (but that's a separate issue).