penny distribution

[John Roth]

"Jess Austin" <austin at smartobject.biz> wrote in message
news:b3ad1da7.0311060640.5759d505 at posting.google.com...
> "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.

Here's one that's even more interesting. I once worked on a payroll
(manual) where one class of employee was payed at a rate with
three decimals - that is, a half cent. This was a union rate, so not
only did we have to distribute the pennies so the actual payroll for
the week came out right, but so that the right person got the extra
penny every other week.

It's not always government regulations...

John Roth
>
> later,
> Jess