[GNC] GnuCash_user: rounding errors and significant digits

Sat Oct 7 15:48:25 EDT 2023

GnuCash does **NOT** round prices to two decimals. Prices are always calculated to the full numeric precision of 1/2^64. Amounts and values are what get rounded to the respective commodity/currency's smallest unit. Since 15000 and 137741 have no common factors GnuCash will represent that as 15000000/137741 internally and by default display it as 10 + 50000/137741. The latter irritates some users so we provide a preference that will display it as a decimal with two more fractional digits than the currency's smallest, so in the case of USD it would display as $10.8900, but the full fraction is what gets used for any computations and stored in the pricedb.

Regards,
John Ralls

> On Oct 7, 2023, at 10:25, David Carlson <david.carlson.417 at gmail.com> wrote:
> 
> According to my HP handheld calculator, 15,000.00 divided by 1,377.41
> yields 10.8900.  According to my hp 49g+ scientific graphing calculator,
> 15,000.00 divided by 1,377.41 yields 10.8900037026.  I defy anyone to pay
> that amount per share in U.S. currency.  I am sure the broker's report
> showed $10.89 per share and $15,000.00 total  paid, which is what GnuCash
> would show if the user selected the price to be calculated instead of the
> total amount according to the attached illustration because GnuCash would
> show the price to the nearest cent . If shares were expressed to three
> decimal places as some brokers' statements do, I suspect the missing digit
> would still be zero and the result would not change for this example  .
> Where is the problem?
> 
> On Sat, Oct 7, 2023 at 11:55 AM Bruce McCoy via gnucash-user <
> gnucash-user at gnucash.org> wrote:
> 
>> Hi Everyone,
>> 
>> On Fri, Oct 6 at 1:02 PM John Ralls wrote:
>>> Book out of balance, meaning that the trial balance
>>> report doesn't balance with the Average Cost price
>>> source, nearly always results from not computing
>>> capital gains/losses correctly. Interpret that
>>> broadly:...
>> 
>> The books are out of balance when either the “Computing cost of goods
>> sold” calculations or the “Average Cost price source” differ from the “the
>> trial balance report” calculations. Both of these are more major points. Is
>> our concern here about a relatively major point or about a relatively minor
>> point?
>> 
>>> GnuCash's rounding isn't likely to put books out of
>>> balance because GnuCash forces transactions to be
>>> balance in the transaction currency.
>> 
>> “GnuCash's rounding isn't likely to put books out of balance” is certainly
>> true. GnuCash's routines have a high degree of precision. I’d say John
>> Ralls’ and Jim DeLaHunt’s work on rational numbers is excellent. GnuCash
>> almost always displays an answer correct to two decimals. Can GnuCash ever
>> put the books out of balance?
>> 
>>> GnuCash forces transactions to be
>>> balance in the transaction currency.
>> 
>> In the transaction currency, GnuCash forces transactions to balance with a
>> high degree of precision. This is certainly true. Does GnuCash force
>> transactions, in the transaction currency, to balance in all cases?
>> 
>> In previous posts, we have mentioned Jeff Earickson's experience and
>> comment.
>> 
>> We mentioned that on a certain day, Jeff entered the number of shares he
>> purchased (1,377.41) and the price per share he paid (10.89). GnuCash
>> calculated the Value of the transaction.
>> 
>> Jeff expected the numbers in his transaction line to be as follows:
>> 
>>        # shares  Price-per-share      Value
>>        1,377.41            10.89  15,000.00
>> 
>> https://tempsend.com/qekjd has Shares_Price_Value_Calculate_gnu.png.
>> Jeff wanted to see something similar.
>> 
>> The numbers GnuCash calculated were as follows:
>> 
>>        # shares  Price-per-share      Value
>>        1,377.41            10.89  14,999.99
>> 
>> Jeff Earickson observed the discrepancy and understood that his books were
>> not in balance due to Ghucash’s calculations. So, Jeff contacted GnuCash.
>> And Mike Novack noticed.
>> 
>> On Sun Feb 23 10:15:34 EST 2014, Mike Novack mentioned Jeff Earickson's
>> comment
>>> "1377.41 x 10.89 = $14,999.99 (one penny off, arrrgh...)"[1].
>> 
>> Jeff seems to want GnuCash to calculate the value of his transaction
>> correctly to, using the convention that ignores the first digit if it is a
>> one, at least 6 significant digits. In this case, GnuCash’s approximations
>> are almost correct.
>> 
>> Jeff wants his transaction line to balance. Jeff states the difference in
>> pennies and also states his reaction to GnuCash’s calculations.
>> 
>> Jeff’s situation is the specific example cited for our discussion of a
>> general situation with GnuCash. This example illustrates the question for
>> consideration.
>> 
>> Our question for discussion is as follows:
>> 
>>> What are the plans to help our users whose
>>> books are out of balance by a cent or so?
>> 
>> 
>> Footnotes:
>> [1]
>> https://lists.gnucash.org/pipermail/gnucash-user/2014-February/053296.html,
>> 
>> https://lists.gnucash.org/pipermail/gnucash-user/2014-February/053299.html
>> .
>> 
>> 
>> 
>> |  | Virus-free.www.avast.com |
>> 
>> _______________________________________________
>> gnucash-user mailing list
>> gnucash-user at gnucash.org
>> To update your subscription preferences or to unsubscribe:
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> -----
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
>> 
> 
> 
> -- 
> David Carlson
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.