prePEP: Decimal data type
Batista, Facundo
FBatista at uniFON.com.ar
Thu Nov 6 13:49:03 EST 2003
More information about the Python-list mailing list
Thu Nov 6 13:49:03 EST 2003
- Previous message (by thread): prePEP: Decimal data type
- Next message (by thread): prePEP: Decimal data type
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
bokr at oz.net wrote: #- I wonder how they deal with compound interest. E.g., may a #- contract for a loan #- express interest as mathematically continuous between #- payments? In that case #- does rounding from mathematically exact values occur only at #- payment times? #- Is the rounding only applied to the payment amount, so that #- the princal is #- decreased by the exact quantized payment, but the balance #- retains exactness? #- Or is requantization of all values mandated at each #- transaction? Is each step in #- a sum a separate transaction? What about the rules for #- pre-tax-calculation subtotals #- vs accumulating actual receipt stated tax amounts? I #- remember as a kid bugging #- store clerks to sell me two candies separately to stay under #- the minimum taxable #- price threshold twice rather than exceed it once and pay the #- extra penny ;-) The problem I see when you round is that d * (a + b) != d*a + d*b i.e.: d = 1.23 a = 5.15 b = 3.66 half-up rounding in two decimals on *each* operation: 1) 10.84 2) 10.83 I think that is up to the human, knowing that he's rounding, to write the expression in one or other way. Maybe following legislation, maybe at random. But it seems to me pretty difficult to the class to predict each behaviour and get the same result in both cases. . Facundo
- Previous message (by thread): prePEP: Decimal data type
- Next message (by thread): prePEP: Decimal data type
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list