Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
resolution: - not a bug
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23201
___
Raymond Hettinger added the comment:
A possibility would be to add (disallowed by the
Decimal standard) to the exception message.
That is what InvalidOperation means ;-)
--
___
Python tracker rep...@bugs.python.org
Terry J. Reedy added the comment:
Thank you Tim.
A possibility would be to add (disallowed by the Decimal standard) to the
exception message.
--
nosy: +terry.reedy
versions: -Python 3.6
___
Python tracker rep...@bugs.python.org
Stefan Krah added the comment:
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).
--
Tim Peters added the comment:
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
Steven D'Aprano added the comment:
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
Devin Jeanpierre added the comment:
Does the spec have a handy list of differences to floats anywhere, or do you
have to internalize the whole thing?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23201
Raymond Hettinger added the comment:
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
STINNER Victor added the comment:
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.
--
nosy: +haypo
___
Python tracker
Raymond Hettinger added the comment:
The docs already reference the spec.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23201
___
___
Mark Dickinson added the comment:
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
Stefan Krah added the comment:
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.
--
___
Python tracker
Devin Jeanpierre added the comment:
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
New submission from Devin Jeanpierre:
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
Changes by Devin Jeanpierre jeanpierr...@gmail.com:
--
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23201
___
___
Ezio Melotti added the comment:
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.
--
nosy: +ezio.melotti, facundobatista, mark.dickinson, rhettinger, skrah
versions:
Josh Rosenberg added the comment:
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
Chris Rebert added the comment:
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
18 matches
Mail list logo
