prePEP: Decimal data type

[Bengt Richter]

On 9 Nov 2003 03:02:21 -0500, aahz at pythoncraft.com (Aahz) wrote:

>In article <jeQr/ks/Kz6B089yn at the-wire.com>,
>Mel Wilson <mwilson at the-wire.com> wrote:
>>In article <vqgapfommnh7db at news.supernews.com>,
>>"John Roth" <newsgroups at jhrothjr.com> wrote:
>>>
>>>My personal opinion in the matter is that setting the precision
>>>high enough so that you won't get into trouble is a hack, and it's
>>>a dangerous hack because the amount of precision needed isn't
>>>directly related to the data you're processing; it's something that
>>>came out of an analysis, probably by someone else under some other
>>>circumstances. Given a software implementation, there's a performance
>>>advantage to setting it as low as possible, which immediately puts
>>>things at risk if your data changes.
>>
>>   It puzzles me.  In the COBOL days, we used to worry over setting the
>>sizes of our data fields large enough.  We'd set a size we thought was
>>ridiculously large and then worry whether today would be the day that
>>the company would do the unprecedented amount of business that would
>>blow up the night-shift batch runs.  We escaped from that with Python's
>>long ints and now we're trying to invent it again.
>
>Division is the fly in the ointment, unfortunately.  The other operations
>lead to unbounded-but-finite number sets; division leads to infinite size
>unless truncated or rounded.
But  (a/b) / (c/d) == (a/b) * (d/c)  == (a*d/b*c) so if you can deal with multiply
you can postpone truncation or rounding if you postpone actual division by maintaining
the separate rational components. Of course (a/b) + (c/d) => (a*d+b*c / b*d)
so you can wind up with a lot of multiplies too, if b!=d. I wondered what was really entailed,
so I wrote an experimental module (exactdec.py, see recent post in this thread (it is very
unoptimized, but it seems to work for interactive purposes)).

At least one can mentally shift to thinking about when and why rounding or truncation
is _really_ necessary in real use cases. Maybe eager rounding is premature optimization
and/or a no-op in a lot of cases (or worse, hidden value transformations that are not
documented as intentional).

I wonder what the legislators would mandate if they thought exact arithmetic was as cheap
and easy as hardware fixed point. Maybe currency exchange rates would be expressed as e.g.
<large_integer_number_of_dollars>/<large_integer_number_of_euros> when they were fixed legally,
and there would be no argument about using the inverse ;-) The problem would move elsewhere.
But where? Well, I don't know, presumably how to round when doing debit/credit across an exact
echange rate to accounts expressed in discrete mimimum quanta.

Hm, ... that's actually not uninteresting ;-) What does currency exchange _really_ mean?
Any given exchange that is not exact could be said to have an exactly defined error in one
or both sides of the transaction. If a price is stated in one currency, that could be presumed
exact. If the other side always truncated down to an exact amount, the exact errors could
theoretically be accumulated in an error bank, doing exact arithmetic summing fractions all
less than 1, determined by the various exchange rates in effect over time.

Ignoring the computing problems, what would be the meaning of the total in that national
error bank at the end of a year? A tax on inexact arithmetic? What is the meaning of ignoring
the amount? A leak in the monetary system? Probably only of theoretical interest compared to
other leaks ;-)

Regards,
Bengt Richter