Problem with round() for rounding numbers 2

[rob444]

I'm having serious problems with rounding numbers with the round() function. (VFP9)

I have 13 different numbers, all up to 8 decimals
They need to be 2 decimal numbers and sometimes 1 decimal numbers.
Those numbers are integer numbers divided by 256.56 and the total of those rounded numbers almost never is 100.

Does anyone have a solution?

Rob

 

[Stella740pl]

I am sorry, I don't understand your problem.

Where 256.56 is coming from and why the total of those rounded numbers is supposed to be 100? Can you elaborate a little?

 

[rob444]

If the total of a few numbers is 25156 and the numbers and percentages are
14139 56.25%
3254 12.94%
6545 26.02%
327 1.30%
56 0.22%
622 2.47%
213 0.85%
------------
25156 100.01%

In order to get the percentages I divide each number by the total/100 which is in this case 251.56

It is curious that round(x,2) often results in 100.01% and that round(x,1) often results in 100.1%

I cannot remember I ever had this problem in previous versions of VFP...

 

[Mike Lewis]

Rob,

I might be missing something here, but surely that's the sort of rounding error you can expect to get when you do this sort of calculation. After all, you are rounding each step of the calculation to two places. VFP is behaving as you'd expect.

By the way, you'll get higher precision if you multiply by 100 first then divide by the total.

Mike




__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[rob444]

Thanks Mike,

I'm going to have a try with your suggestion!

Rob.

 

[Stella740pl]

Besides that, do all your intermediate calculations with a precision 2-3 decimal positions higher than you actually need, and round to 1-2 decimal positions only the final result.

And in addition, on many of my reports of this sort there is a disclaimer, something like "The numbers may not add up to the total due to rounding", or alike.

 

[dbMark]

You could fix that rounding issue by saving additional information when making your calculations. When running it, track the item that is the greatest rounded amount "off" (comparing values before and after rounding), saving the greatest positive variance and greatest negative variance. Then if the total does not exactly equal 100.00, adjust the greatest variance up or down as appropriate.

There's no guarantee thet's the best way to handle it, but it most likely is one alternative.

Like Stella said, there's nothing wrong with a disclaimer about rounding variances unless the finished product just isn't allowed to display slight variances. And 99.99 is just as bad as 100.01, the customer always asked where that 0.01 went!

dbMark