prePEP: Decimal data type

[Ron Adam]

On Thu, 6 Nov 2003 10:43:52 -0500, "Tim Peters" <tim.one at comcast.net>
wrote:
>I'd be astonished if the rules were consistent enough so that a type
>implementing a fixed number of decimal digits "after the decimal point"
>would be of real use for non-experts ... OK, here from:
>
>    http://www.eubusiness.com/emu/retail8.htm
>
>    The conversion of prices into euros will require the use of a six-
>    significant-digit conversion rate (six digits disregarding initial
>zeros)
>    which should not be rounded or truncated. This rate will be irrevocably
>    fixed on 1 January 1999 and defined in the form of one euro expressed in
>    national currencies.
>
>So that part mandates a *floating* point input (not meaning binary floating
>point, but "6 digits disregarding initial zeros" is the essence of floating
>point -- the total number of digits isn't fixed, nor is the # of digits
>after the decimal point fixed, just the # of *significant* digits).
>
>    To convert from national currencies to the euro, one has to divide by
>    the conversion rate.  To convert from the euro to the national currency,
>    one has to multiply by the conversion rate.  The use of inverse rates is
>    forbidden.
>
>Neutral.
>
>    To convert from one national currency to another, amounts must be first
>    converted into euros and then into the second national currency.  The
>    euro amount must be rounded to three decimal places.  The national
>    currency should then be rounded to two decimals.
>
>So no single fixed-point discipline can suffice:  in one direction they want
>rounding to 3 digits after the decimal point, in the other to 2 digits, and
>one of the inputs is a floating-point value with no fixed number of digits
>after the decimal point.
>
>This is all very easily done with IBM's proposed arithmetic, but it requires
>the programmer to specify explicitly how many places after the decimal point
>they want after each * and / operation.  Since that value changes in
>arbitrarily (from the POV of arithmetic semantics) mandated ways, no class
>can guess what's required from step to step.
>

I agree with you on this, and this is an excellent example of the
situation. 

I believe a general use built in decimal type which addresses the
problems with floating point would be great.  It should have good
general numeric tools to manipulate the numbers and digits, including
rounding up or down but maybe not rounding even.  A function to count
the number of digits before and after the decimal place might be good.
I just looked for that one and didn't see it in the math.py or
cmath.py modules.  I was thinking of using it to round the decimal
portion of a number to one less digit to compensate for the floating
point internal base two representation.

As for accounting specific features,  I really think a good separate
accounting math module would be better choice.  It could have a rich
set of functions  for calculating interest rates and Time-Value-Money
calculations such as mortgage payments, and loan Amortization lists
along with round_even and include most functions that one would find
on a business calculator or in a spreadsheet for that purpose. There
could also be euro/country specific functions if they are needed.  A
module such as this may be able to support localization better than
trying to build it in.  

I don't know (yet) how python handles things internally since I'm
still new with it, but I lean towards not letting the core get too
bloated or specialized, especially if it will slow it down in any way.
When it comes to numbers, speed is important.    

By the way,  I haven't seen anything yet on how fast the decimal type
will be compared to floats and ints?  From reading the specs on it I
get the impression its slower than ints but has compression so uses
less memory, but I was wandering how much slower?  Or maybe it isn't
slower if it is handled as an integer with a base ten integer
exponent?

_Ronald Adam
radam2 at tampabay.rr.com