Guido van Rossum wrote:
Guido van Rossum wrote:
int/long < decimal < rational < float < complex \---------------------------/ \-------------/ exact inexact
Note that in Cowlishaw's implementation of decimal numbers, decimals are *not* exact. Truncation (rounding), overflow, and underflow errors can occur under addition, subtraction, and multiplication. It's trivial to set them to be unbounded, but then Cowlishaw provides no mechanism for determining the truncation of division.
I know all that. Cowlishaw's numbers are a replacement for float (and for the real/imag parts of complex). I was toying with a *different* idea, more appropriate perhaps for accountants, that guarantees exact results for decimal numbers, giving decimal results when possible, rational otherwise. This is based on my guess about Michael's target audience. Michael makes a big deal of not allowing "decimalness" to be contaminated by mixing with floats. Possible this could be implemented using a subclass of your decimals that uses unbounded precision but overrides division to produce a rational number if needed.
But it's possible that Michael's audience would in fact be very happy with your/Cowlishaw's decimal numbers.
I believe that Rationals should form the basis for Decimal types -- the different possible semantics can then be added either by subclassing Rationals or by providing some context or specialized methods for different operations, e.g. for special rounding requirements like you have in financial applications. Note that I implemented mxNumber for just this reason (the float and long integer support is merely a side effect of GMP providing it ;-). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/