[GNC] GnuCash_user: rounding errors and significant digits

Bruce McCoy email_bnj_now at yahoo.com
Wed Oct 25 20:00:01 EDT 2023


 Hi Everyone,

On Sun, Oct 8 at 5:31 AM sunfish62 wrote:
    >I'm not sure whose problem is being solved by 
    >this drawn out discussion. 
    >
    >⁣David T.

David, you are right. It is a drawn out discussion. 

On Sat Oct 7 17:27:29 EDT 2023 Maf. King wrote: 
    >going around in circles.

Exactly. Aren't there at least two perspectives?
Observer: 
     Bruce, you are going around in circles. 
     You do not seem to be making much, if any, progress.
Participant:
     I circle around, trying to see it from every angle.
     I do not seem to be making much, if any, progress.

Why are we doing this? We help ourselves, if we make GnuCash easy to understand and use. People unfamiliar with GnuCash conventions may find notes on how to understand GnuCash helpful. 


Assumptions
===========
On Sat, Oct 7 at 4:06 PM John Ralls wrote: 
    > GnuCash has no support for cost accounting


On 2023-09-09 15:36:40 EDT, John Ralls wrote:
    >So the claim value = price * shares is logically 
    >correct but depends on price * shares yielding 
`    >a legal value in value's currency; the reverse 
    >is true as well: shares = value/price is true 
    >only if value/price produces an amount representable 
    >in the share commodity's minimum fraction.

In the following, we assume "value/price produces an amount representable in the share commodity's minimum fraction."

We also assume that an "exactly precise" number has the same precision as the smallest currency unit (SCU).


Considerations
==============
On Sat Oct 7 15:48:25 EDT 2023 John Ralls wrote:
    >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.

John, GnuCash does an excellent job calculating its results. The discussion here is mostly meant to be one in which we generate an explanatory note in the documentation to help newcomers to understand how to think about the way GnuCash may differ from what is familiar to them. Your rational number and your full numeric precision calculations are outstanding. You have done yeoman work on this project, as for as I am concerned.

GnuCash treats the smallest currency unit as an exactly precise number[1].

On Sat, Oct 7 at 1:25 PM David Carlson wrote: 
    >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.

David Carlson follows the GnuCash example in recognizing that the SCUs are exactly precise (Who pays $0.0000037026?) and only the number-of-shares figure can be an approximation.

On Sat, Oct 7 at 4:06 PM John Ralls wrote: 
    >Jeff did it wrong...because the price per share 
    >he paid wasn't 10.89, it was 137741/1500000.

$10.89 is an exactly precise figure. 1500000/137741 is a very close approximation.

    >It's simpler to enter the amount and value 
    >than to enter an exact price.

Dividing the value-of-the-transaction by the amount-of-shares involved yields the price-per-share. I am sure you have a good reason for designing GnuCash with the convention of calculating price-per-share from the other two variables. Could you share how you arrived at this decision?

On 2023-09-09 15:19:53 EDT, Ken Farley wrote:
    >The key equation is AMOUNT = PRICE * SHARES...
    >What I really care about when I get my statements 
    >from investment institutions, or trade 
    >notifications, is the number of SHARES involved
    >and the total cost to me.

On 2023-09-09 15:41:46 EDT, Stan Brown wrote:
    >It is _mathematically_ not possible to have three 
    >decimal numbers A B and C, each rounded to a 
    >desired number of decimal places, fulfill the 
    >equation A * B = C exactly... Number of shares 
    >and total amount must be exact to the generally 
    >accepted numbers of decimal places, or people's 
    >books won't balance.

According to GnuCash SCUs are exactly precise, so the number-of-shares is the only number which can be less than exactly precise due to rounding, for example, by institutions. Investors, as clearly stated by both Ken and Stan, accept the rounded number-of-shares values since they are the number-of-shares allotted to them in the transaction.

Evaluation
==========
In stock transactions, 
Value-of-the-transaction =  Price-per-share * Number-of-shares.

Financial firms treat SCUs as exactly precise figures, and the number-of-shares, when required, as an approximation. GnuCash does treat the value-of-the-transaction SCU as an exactly precise figure. 

In its internal calculations, GnuCash differs from financial firms in its treatment of the number-of-shares and the price-per-share figures.

First, GnuCash treats the number-of-shares figure, despite its possibly having a rounding error, as though it were exactly precise. Second, GnuCash treats the price-per-share figure, even though it is exactly precise, as though it were an approximation, because, of the three figures, only two can be exactly precise. 

Let us look at an example.

On Sat, Oct 7 at 4:06 PM John Ralls wrote:
    >Jeff did it wrong. Jeff should enter the number of shares 
    >and the amount paid and let GnuCash calculate the price, 
    >because the price per share he paid wasn't 10.89, it was 
    >137741/1500000. 137741 is the product of two primes, 
    >181 and 761, so 137741/1500000 *cannot* be exactly 
    >represented as a decimal. It's simpler to enter the 
    >amount and value than to enter an exact price.

Both GnuCash and the financial statements agree that the amount paid is an exactly precise figure. This leaves the number of shares and the price per share for discussion. GnuCash assumes that the number of shares is an exactly precise figure. If so, "the price per share he paid wasn't 10.89," it was, as we know, since we are using GnuCash, an extremely accurate figure (1500000/137741), but not an exactly precise figure.

A financial statement assumes that the price per share is an exactly precise figure. As GnuCash users, we can help GnuCash novices by explaining two things. One is a functional explanation e.g. "enter the amount and value." Many of the GnuCash users and developers have expressed the same idea in similar terms. Here are four examples.

David Carlson Sat, Oct 7 at 11:07 PM said: 
    >What you do not understand is that John Ralls 
    >and GnuCash recommend entering the total amount 
    >and the total number of shares and letting 
    >GnuCash calculate the price. THEN there is 
    >no error in the account running balance.  
    >This is not going to change.

On 2023-09-09 15:19:53 EDT, Ken Farley wrote:
    >The key equation is AMOUNT = PRICE * SHARES...
    >What I really care about when I get my statements 
    >from investment institutions, or trade 
    >notifications, is the number of SHARES involved
    >and the total cost to me.

On 2023-09-09 15:41:46 EDT, Stan Brown wrote:
    >It is _mathematically_ not possible to have three 
    >decimal numbers A B and C, each rounded to a 
    >desired number of decimal places, fulfill the 
    >equation A * B = C exactly... Number of shares 
    >and total amount must be exact to the generally 
    >accepted numbers of decimal places, or people's 
    >books won't balance.

On Sun, Oct 8 at 5:31 AM sunfish62 wrote:
    >FWIW, Jeff reported his problem in 2014, and was 
    >happy when Derek advised him to enter the number 
    >of shares and the total dollar amount of the 
    >transaction, leaving the price to be calculated. 
    >
    >⁣David T.

You have been very gracious in giving a functional explanation on what to do to minimize displaying erroneous results on the screen.

In our documentation, have we given our novice users an explanatory note as to how GnuCash differs in its calculation assumptions from those used in other areas of the financial world? No, we have not yet. 

>From the viewpoint of the financial world, in general, the price per share is the exactly precise figure. They say, "Jeff did it right. Jeff paid $10.89, not $137741/1500000. Jeff bought 1377.41046831955922 shares, not 1377.41 shares."
We should not let the excellence of GnuCash's estimation obscure the fact that the number-of-shares must be the approximation, since SCUs are exactly precise figures. 

Our second task is to explain that clearly. If we don't, could we confuse people?

On a similar note, 
On Sun, Oct 8 at 5:47 AM David Carlson responded:
    >"Perhaps the broker overcharged his client...
    >
    >> > Because the broker charged 15,000.00 for 1,377.41 shares?
    >>
    >> Then the effective price paid per share wasn't the stated 10.89 but
    >> slightly more (approx 10.890003702601258884)"

Yes. If the brokers round down, they will increase "the effective price paid per share" on each trade.


Suggestion
==========
Could we consider putting some text into GnuCash Tutorial and Concepts Guide, Part II. The Common Usage, Chapter 9. Investments, Buying Shares, Entering Preexisting Shares? The note currently says, "Note It is also possible to use GnuCash to calculate Shares or Buy from the other 2 columns. But to avoid rounding errors, it is better to automatically calculate Price." That Note could be amended with something like the following text.

"In stock transactions, 
Value-of-the-transaction =  Price-per-share * Number-of-shares.

Financial firms treat SCUs as exactly precise figures, and the number-of-shares, when required, as an approximation. GnuCash does treat the value-of-the-transaction SCU as an exactly precise figure. 

In its internal calculations, GnuCash differs from financial firms in its treatment of the number-of-shares and the price-per-share figures.

First, GnuCash treats the number-of-shares figure, despite its possibly having a rounding error, as though it were exactly precise. Second, GnuCash treats the price-per-share figure, even though it is exactly precise, as though it were an approximation, because, of the three figures, only two can be exactly precise."

Might this help people like Jeff? What do you think?

Best Regards,
Bruce



Footnotes:
[1] ex. GnuCash Tutorial and Concepts Guide, Figure 9.14. The Price Database With The List Of All Known Commodities



|  | Virus-free.www.avast.com |



More information about the gnucash-user mailing list