[GNC] GnuCash_user: rounding errors and significant digits

Michael or Penny Novack stepbystepfarm at comcast.net
Tue Sep 26 09:14:23 EDT 2023


On 9/25/2023 9:50 PM, Adrien Monteleone wrote:
> It still did not come through as you likely can't send zip files 
> through this mailman instance.
>
> What exactly are you sending, just images? Attach them individually, 
> or else post them on a hosting site and simply paste the links in 
> another reply. 


But perhaps more basic, necessary is an understanding of what is meant 
by "rounding errors".

When performing arithmetic operations with EXACT values we can expect to 
get the same final result regardless of the order in which the 
operations are performed (as long as a legal order).

When performing arithmetic operations with ROUNDED values we can NOT 
expect to get the same final result. By which I mean that in general the 
final result will depend on the order of operations, where rounding 
takes place, and on the "location" of rounding (how many decimal places, 
how many significant digits retained, etc.).

For example ---- A x (B - C) can be quite different from (A x B) - (A x 
C) if A is large and B and C close in size. Even when all we are doing 
is adding, the final result of Rounded A + Rounded B + Rounded C + 
........ + Rounded X + Rounded Y can be quite different from Rounded ( A 
+ B + C + ..... + X + Y) if that is large number of terms.

So ..... when you say "error" you SHOULD mean "given a specified order 
and points of rounding". But if you are talking about differences caused 
by different order of operations and points of rounding you should be 
using some other term than "error". It is quite valid to argue in favor 
of a different order of operations or points of rounding but not to call 
some other order or points of rounding WRONG. Not unless a claimed value 
of "fuzz" is not being met.

And I am unaware of gnucash promising some maximum value of "fuzz"

LOL --- I have filled out many government filings where a specified 
(final) point of rounding was required. For example, "file amounts in 
whole dollars". But since that report might also require showing 
individual amounts and subtotals of various of them in addition to final 
totals, everything in whole dollars, and in balance, a certain amount of 
juggling can be required. Requires fudging some of the amounts up or 
down a bit instead of using the "correct" rounded amount. USUALLY, with 
careful choice of which amounts, can be done by the substitution of 
"floor" for "rounded" for just a couple amounts. The "sport" is figuring 
out the minimum amount of fudging required.


Michael D Novack



More information about the gnucash-user mailing list