On Wed, Aug 28, 2013 at 11:53 AM, Oscar Benjamin <oscar.j.benjamin@gmail.com
wrote:
On Wed, Aug 28, 2013 at 12:30 PM, Vernon D. Cole <vernondcole@gmail.com> wrote:
Darn right it should return False. Given the principle of least
surprise
(and my prejudices built up over 40 years as a computer programmer) I would expect that decimal.Decimal data would be stored internally as some
On 28 August 2013 11:48, Draic Kin <drekin@gmail.com> wrote: form of
decimal data, and would store into a database as such. It would be expected to be in a fixed point format. Real, on the other hand, I would expect to be stored as an IEEE double precision floating point number, or something like that. I don't care whether a fixed point decimal number might be defined by a mathematician as "real" -- I care whether it can be processed by an FPU, and whether it will loose precision in large financial calculations.
Decimals are effectively stored internally as integers.
That surprises me, a bit, but given the efficiency of modern 64 bit processors it's not a bad choice. We've moved on from the day when CPUs like the Intel 4004 and the IBM 360 expected to do most of their work in Binary Coded Decimal.
They won't be processed by the FPU which operates on binary floating point types.
_Exactly_ my point.
Also the decimal module has traps for people who want to prevent inexact etc. operations.
For the same reason, I could think that isinstance(Decimal, Rational) -> True and issubclass(Rational, Real) -> False. It's more about exact vs. non-exact computations which is orthogonal to number hierarchy. Maybe there should be some ExactNumber abstract base class and some convention that exact shouldn't coerce with non-exact. So Decimal + float should raise an exception even if both would be subclasses of Real (and Decimal even of Rational). Or maybe it would be enough if there were just non-exact variants of Real and Complex since non-exactness if just issue of them.
That's it. This is a "practicality beats purity" issue. Python types Real and Complex are not exact because we usually don't need exact. "Close enough" is enough. I know that 3.14159 is not the true value for Pi, but it suffices when I am trying to figure out how fast a vehicle will travel with a given size tire. Now, consider when I am processing the arguments for an SQL "execute" method. [*] How do I prepare the values for the underlying db engine? I use a long list which includes lots of "elif isinstance(value, <some Python type>):" The code for "isinstance(value, Real)" is quite straight forward. The code for "isinstance(value, decimal.Decimal)" requires 18 lines of incredibly obscure Python. I really do need to be able to tell them apart. I agree that an Exact ABC would be good. The PEP has a reference to
exact as a superclass of Rational but I guess it's just left over from a previous edit: http://www.python.org/dev/peps/pep-3141/#numeric-classes
Oscar
[*] For this example, I am referring to the code in http://sf.net/projects/adodbapi of which I am the maintainer.