Re: Half Adjust

[G Armour <garmour400r@xxxxxxxxx>]

In reply to Buck's suggestion, FWIW, and in part to make amends for my previous
mis-post, I offer a pseudo-technique that I saw quite a few years ago that best
attacks the precision issue.  (Note: This is OVERKILL for most situations; I've 
only
ever seen this used once in production, but discussed many times for dealing 
with
this issue.)  In your example,
>                  trunc
>           1   .0588
>           7   .4117
>           6   .3529
>           3   .1764
>  Total:  17   .9998

Since the assumption in this example is that a precision of 4 decimal places is
desired, carry the division out to a few more decimal positions.  Let's say 7
decimal positions:

           1   .0588|235
           7   .4117|647
           6   .3529|411
           3   .1764|705
  Total:  17   .9998

Using this technique, you would add .0001 to the values with the highest two (to
make up for the missing .0002) least significant digits beyond the precision 
you are
using.  In the example above, I use a separator to show the least significant
digits.  .0001 would be added to the 2nd and 4th elements:

           1   .0588
           7   .4118
           6   .3529
           3   .1765
  Total:  17  1.0000

HTH, GA
--- Buck <buck.calabro@xxxxxxxxxxxx> wrote:
<snip>
> Another possibility is to keep a running total of the fractional amounts and
> when you get to the last entry, subtract that from the total (100) and use
> the subtracted difference rather than to calculate the last percentage by
> division.
> 
>                  trunc
>           1   .0588
>           7   .4117
>           6   .3529
>           3   .1764
> Total 17  .9998
> Adjust final entry by subtracting running total from desired total (1.0000 -
> .9998 = .0002)  Add .0002 to .1764 and print that.
> 
> This method is expedient but may result in quite a large mis-statement
> (percentage wise) of the true value of the last entry.  An alternative is to
> perform the same manipulation, but apply it to the largest entry in the
> list, thus minimising the percentage effect of the rounding on any
> individual entry in the list.
> 
> In the above example, you would add the .0002 to .4117 instead of .1764,
> thus distributing the rounding error to the value which can absorb it
> easiest.
>   --buck



__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com