proposed language change to int/int==float (was: PEP0238 lament)

[Lloyd Zusman]

Guido van Rossum <guido at python.org> writes:

> [ ... ]
> 
> I think you're right.  An early version of ABC worked like this, and
> at the time I though "hmm, but why shouldn't 0.98 be an exact
> number; it could be intended as a price or something like that", and
> I convinced the team to change it.  But in practice it was more
> often annoying.  Now maybe that was because we (the biggest users)
> were CS and math folks, and we tended to tackle typical math and CS
> problems -- but my gut is to vote against this aspect of the PEP.

Lately I've been consulting on Wall Street, and it turns out that in
the computations done in that universe, there is a great need for
non-float decimal types, such as your example about 0.98 being used as
a price.

Accountants and their kin want ledgers, positions, etc. to balance to
the penny (or centavo, or whatever is the smallest fractional currency
in a given country).  This can only be accomplished using decimal
arithmetic ... like Bignums with implied decimal places.

I believe that this kind of exact decimals would be very useful,
although I agree that there should be some new way to represent these
values (so that 0.98 in a Python program would still be considered a
float).

Decades ago, IBM had a fairly useful solution to this: since the
1960's, their mainframes have had packed decimal arithmetic
implemented within the standard instruction set.  This type provided
integer-like arithmetic and managed implied decimal places.  These had
a maximum of something like 18 digits, so we're not dealing with
Bignums exactly, but this data type still worked well enough for the
vast majority of accounting-related applications done on IBM
mainframes.  There's no coincidence that IBM (note the middle initial)
designed their machines to cater to the computing needs of businesses.

I wrote a C library of arbitrary precision math routines around 12 or
13 years ago (and I hear that a version of it is still floating around
the net somewhere, in case anyone is interested; it's called APM).  It
essentially consisted of Bignums with a specified decimal precision
for each calculation.  Division yielded remainders.  This was needed
for a currency trading application for which I was one of the
designers and developers.

On this project, my comp sci colleagues originally argued vociferously
against decimal math and maintained that double precision floats would
be more than sufficient.  However, when the clients (financial firms)
saw that their positions at the end of the day were off by a small
amount due to the errors inherent in floats, my cohorts suddenly
became quite happy (and even a bit insistent) about me writing the
decimal arithmetic routines.

So anyway, I would argue that some sort of exact decimal type is also
necessary for doing financial calculations that have to balance "to
the penny".  If a rational type is used to implement this, it would
have to be a special case, where the denominator of the rationals
would always have to be fixed when doing financial calculations (for
example, the denominator would usually have to be 100 for the results
of calculations involving US dollars and cents).  And once again, this
numeric type would have to do integer-type division and yield
remainders.

I just thought that I'd add some more mud to the waters of this
thread.  :)

[ Should this be a PEP? ]


> [ ... ]


-- 
 Lloyd Zusman
 ljz at asfast.com