penny distribution

Jess Austin austin at smartobject.biz
Thu Nov 6 09:40:55 EST 2003


"Batista, Facundo" <FBatista at uniFON.com.ar> wrote in message news:<mailman.466.1068053942.702.python-list at python.org>...
> austin at smartobject.biz wrote:
> #- distribute product(m, a, b, c) ~= [m*a, m*b, m*c]    and 
> #- sum(distribute product(m, a, b, c)) = m*(a+b+c)
> #- 
> #- I.e., the first equality is approximate but the second is 
> #- strict.  You
> #- could define Alex's divideBy method as:
> #- 
> #- def divideBy(self, N):
> #-     return distribute product(self, *[1.0/N for i in range(N)])
> 
> But, also I can say that 
> 
> 	def distribute product(multiplier, *portions):
> 		return [multiplier*portion for portion in divideBy(portions)]
> 
> So, divideBy is the general case.
> 
> The importance of this is that because of rounding, both approachs 
> don't
> have the same results (I think)!
> 
> So, which one is valid?

You're right; they don't have the same results.  And I confess that
after more consideration I'm a bit unsure about my redefinition of
divideBy().  My point is that often we have to specify some level of
aggregation at which all rounded amounts must sum exactly to some
other rounded amount.  Thus we need a way to rejigger all rounded
amounts at some more granular level.

Let me try another way of saying this.  A number with a small number
of decimal places is equivalent to an integer, as was pointed out
before.  People don't expect division of integers, or multiplication
of integers by reals (and I still think the former is a subset of the
latter) to yield exact integer answers.  There will obviously be some
rounding involved, although some people might want to specify exactly
how that rounding takes place.  However, most people expect addition
and subtraction of integers to yield exact integer answers.  An
itemized invoice that contains percentage taxation or discounting
(i.e., most invoices I've seen) enforces some sort of distributive law
on inexact multiplication and exact addition.  A program that
generates such an invoice must have some way of adjusting the
multiplication to safisfy the distributive law.  Invariably, attempts
to adjust addition instead make customers very unhappy.

Maybe this application isn't what you were aiming for with your money
class.  But since there was much discussion of rounding, I thought you
might want to consider this situation as well.  It seems a common one
to me, although I haven't read about it in any of the online money
articles.  I'll admit that I don't know the solution I'm seeking, but
now I might have at least stated the problem.

later,
Jess




More information about the Python-list mailing list