prePEP: Decimal data type
Tim Peters
tim.one at comcast.net
Tue Nov 4 19:50:43 CET 2003
[Alex Martelli]
> #- The Decimal type discussed in this PEP is the arithmetic fundament
> #- for Money. Facundo started out with the idea of a PEP for a type
> #- named Money that mixed arithmetic, parsing and formatting concerns.
> Are you sure? Because, for example with a precision of 9:
[Facundo Batista]
> Are you sure? Because, for example with a precision of 9:
>
> 123 --> 123e0
> 1122334455667788 --> 112233445e7
>
> Meaning that you lost the last digits. We're talking about billions
> here, but an accounting person won't be happy with that.
Then they shouldn't use such a tiny precision; that's essentially IEEE
single precision. Default to a precision of, say, 100, and you can count
the number of electrons in the universe exactly. Since each penny contains
at least one electron ... <wink>.
> I think that for Money with need a Fixed Point Decimal, but that's a
> whole new problem.
You really don't. Cowlishaw's spec provides all you really need (wrt
arithmetical semantics) from a fixed point type, provided only that you ask
for enough precision in advance. A precision of 100 is absurdly large for
any conceivable accounting application. A precision of 20 would be way more
than enough to account for total world economic output, down to the penny,
since the beginning of time -- remember that the number of exactly
representable quantities grows exponentially with precision.
> ...
> And I'm not quite sure that I understand what you mean with "unbounded
> precision" (that you can not say with fixed or floating point). Could
> you please explain that? thanks!
Unbounded precision ("to the left" of the radix point) is what my old
FixedPoint.py class did/does: if you multiply two FixedPoint integers, the
result is exact, no matter how many decimal digits the exact product
requires. The IBM spec allows for setting precision, but once set results
are always rounded to that precision. IOW, under the IBM spec the precision
is an upper bound on the number of significant digits in a result (but is a
user-settable upper bound). In FixedPoint there is no upper bound. In
REXX, people wanting the effect of unbounded precision usually set DIGITS
(analogous to the spec's precision) to, e.g., 999999999. Not a good idea
for most divisions <wink>, but for + - and * you'd run out of memory before
a result ever got rounded.
More information about the Python-list
mailing list