[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