Stefan Krah stefan-use...@bytereef.org added the comment:
This whole thing is indeed a matter of taste, so I'd close the bug if no
one else is interested.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7049
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
I would like to look at this for a bit before it gets closed.
--
assignee: mark.dickinson - rhettinger
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
Mark Dickinson dicki...@gmail.com added the comment:
Raymond, can I recommend deprecating and eventually removing three-
argument pow support from Decimal?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7049
Stefan Krah stefan-use...@bytereef.org added the comment:
Deprecate on the grounds that it is slow in decimal.py or the
InvalidOperation issue?
I think pure integer arithmetic with the decimal type always requires
attention from the user, since in many functions one has to check for
Mark Dickinson dicki...@gmail.com added the comment:
I was suggesting that it be deprecated on the grounds that:
(1) It's not part of the Decimal standard.
(2) It's not implemented for Python (binary) floats, so why implement
it for decimal floats?
(3) It's severely use-case challenged.
Stefan Krah stefan-use...@bytereef.org added the comment:
(1) is clearly true. I wonder about (2) and (3):
The decimal data type is specified to be usable for integer arithmetic.
With a high precision (and traps for Rounded/Inexact) I think it's
reasonably convenient to use.
--
Mark Dickinson dicki...@gmail.com added the comment:
Shrug. That doesn't really bother me. x**y%z and pow(x, y, z) aren't
going to match anyway, as soon as x**y has to be rounded.
What would bother me more is the idea of having, with precision 4:
pow(3, 22, 12347) - nan
pow(3, 23, 12347) -
New submission from Stefan Krah stefan-use...@bytereef.org:
If precision 1 is aupported, the following results should not be NaN:
Python 2.7a0 (trunk:74738, Sep 10 2009, 11:50:08)
[GCC 4.3.2] on linux2
Type help, copyright, credits or license for more information.
from decimal import *
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7049
___
___
Mark Dickinson dicki...@gmail.com added the comment:
This behaviour was deliberate: since the standard doesn't cover three-
argument pow, I more-or-less made up my own rules here. :)
In this case, I (somewhat arbitrarily) decided that to ensure that any
possible pow(a, b, m) result could be
Mark Dickinson dicki...@gmail.com added the comment:
Unless anyone else disagrees, I'm going to call this a 'won't fix': I'm
happy with the current behaviour. I would like to relax the condition on
the modulus from 'modulus 10**prec' to 'modulus = 10**prec', though, so
I'm leaving the
Mark Dickinson dicki...@gmail.com added the comment:
Here's a patch.
--
keywords: +patch
Added file: http://bugs.python.org/file15031/issue7049.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7049
Stefan Krah stefan-use...@bytereef.org added the comment:
I don't think early abortion based on m and the current precision is a
good idea. Then we have the situation that this works (prec=4):
(Decimal(7) ** 2) % 10
But this does not:
pow(Decimal(7), 2, 10)
--
13 matches
Mail list logo
