PEP 327: Decimal Data Type

[Stephen Horne]

On 5 Feb 2004 09:18:12 -0500, aahz at pythoncraft.com (Aahz) wrote:

>In article <ad052e5c.0401310101.1c5bd5aa at posting.google.com>,
>Dan Bishop <danb_83 at yahoo.com> wrote:
>>
>>For money, it means that I have *exactly* $1.80.  This is because
>>"dollars" are just a notational convention for large numbers of cents.
>> I can just as accuately say that have an (integer) 180 cents, and
>>indeed, that's exactly the way it would be stored in my financial
>>institution's database.  (I know because I used to work there.)  So
>>all you really need here is "int".  But I do agree with the idea of
>>having a class to hide the decimal/integer conversion from the user.
>
>Really.  What kind of financial institution was this?  They didn't need
>to deal with any form of fractional pennies?

Does it really matter if they did? They may not deal in whole pennies,
but I seriously doubt that they need infinite precision - integers
with a predefined scaling factor (ie fixed point arithmetic) will, I
suspect, handle those few jobs that counting in pennies can't.

For instance, while certainly exchange rates involve fractional
amounts (specified to a fixed number of places), the converted amounts
will be rounded as account balances are recorded to the nearest penny,
unless I'm very badly mistaken. The same applies to interest - the
results get rounded before the balance is affected.

So if the exchange rate is 1.83779 dollars to the uk pound, who can't
cope with the following code?

  exchange_rate = 183779

  result = pounds * exchange_rate / 100000

Assuming that rounding matches the programming languages default
behaviour, of course, and that the width of the integers is
sufficient.


That said, as I understand it, a lot of financial institutions have a
lot of COBOL code. And from what I remember of programming in COBOL,
the typical representation of numbers in both files and working
storage uses decimal digits stored in a character string - at least
that's what the picture strings specify in the source code. Given that
the compiler knows the precision of every number, and assuming that
there is no conversion to a more convenient representation internally,
it shouldn't make much difference whether the number has a point or
not.


Personally, I wouldn't want to contradict Dan Bishops claims - he has
the experience in a financial institution, not me - but I suspect
there is a fair amount of code used in many financial institutions
that does in fact use a decimal representation, if only because of old
COBOL code.


-- 
Steve Horne

steve at ninereeds dot fsnet dot co dot uk