[GNC] GnuCash_user: rounding errors and significant digits

[Jim DeLaHunt]

Bruce:

Again, I think you are holding fast to assertions which I think are 
mistaken, and which lead you to misunderstanding. Let me highlight a few 
in your most recent message.

On 2023-10-25 17:00, Bruce McCoy via gnucash-user wrote:
> ...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).

I think these are assumptions are faulty. The will lead you to 
misunderstandings in a few paragraphs.

It is not always the case that value/price, where value price are number 
in the smallest currency unit, produce an amount representable in the 
share commodity's minimum fraction.  For instance, suppose you want to 
buy shares of Berkshire Hathaway at market price (171.10 USD just now) 
and you have 1000.00 USD. Your unhelpful broker only lets you buy whole 
shares, so the share commodity's minimum fraction is 1.0:

    value = 1000.00 USD (in smallest currency unit)
    price = 171.10 USD (in smallest currency unit)
    value/price = 10000/1711 shares precisely =~ 5.8 shares (approximately)
    value/price is an amount, approx 5.8, which is not representable in
    the share commodity's minimum fraction.

I believe that your definition of "exactly precise" is different from 
the plain meaning of the words. The plain meaning is that an "exactly 
precise" representation of a number is a representation which exactly 
conveys the true numerical value. Thus, decimal number "0.3" is an 
exactly precise representation of the rational number 3/10, but decimal 
number "0.3333" is not an exactly precise representation of the rational 
number 1/3.


> ...GnuCash treats the smallest currency unit as an exactly precise number[1].
> [1] ex. GnuCash Tutorial and Concepts Guide, Figure 9.14. The Price Database With The List Of All Known Commodities

I don't think that Figure 9.14 justifies your claim about GnuCash 
behaviour. Your words mean, "GnuCash treats the smallest currency unit" 
as a number with "the same precision as the smallest currency unit 
(SCU)." It is a tautology.

Maybe you see that the AMZN stock Price entries in that Figure as being 
of the form "35.990000" and assume that GnuCash is limited to only 
represent prices to two decimal digits of US dollars. But it may well be 
that GnuCash would happily store a price with a greater precision, e.g. 
"3,567.523217", or rational numbers not representable in six digits 
after the decimal, e.g. 99123457/3567520000 . Figure 9.14 does not show 
you either way. (Narrator: in fact, GnuCash would.)


> ...
> 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.

I believe you are missing David Carlson's point. I believe he was saying 
that the stock broker's price of "10.89" was clearly not the precise 
price paid, so the _price_ was 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.

I think this is where your definition of "precise figure" is leading you 
astray. The transaction amount and the number of shares reported by the 
broker had numerical values which exactly matched the broker's 
representations. "$10.89" is the broker's approximate representation of 
the actual numerical value, which is amount/quantity, or 1500000/137741.


>      >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?

I think people arrive at this decision because it gives correct results. 
Conversely, treating an approximate representation of a price as exact, 
leads to misunderstanding and to incorrect results.


> 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.

Your premise is faulty; GnuCash does not insist that smallest currency 
units are "exactly precise" according to your definition.  Your 
conclusion, "the number-of-shares is the only number which can be less 
than exactly precise due to rounding", is faulty. Any of the numbers 
reported by the broker can be imprecise, that is, be reported with a 
representation which does not convey the true numerical value.

However, in the broker statements I receive, I can check the transaction 
amount values and share quantity values and against other figures and 
confirm the exact numerical value. Usually the representations turn out 
to be precise. The price exists in isolation; I can confirm it only by 
reference to the transaction amount value and share quantity value of 
that transaction. It is common for the representation of the price to 
not precisely convey the numerical value of amount/quantity .


> ...Financial firms treat SCUs as exactly precise figures, and the number-of-shares, when required, as an approximation....

Why do you believe that this assertion is true? Why do you reject the 
alternative assertion, that financial firms precisely represent 
transaction amount values and quantity of shares in their statements, 
and represent the price as an approximation?


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

This conclusion is correct only if your assertion is correct. I believe 
your assertion is incorrect, and that GnuCash agrees with financial 
firms in its treatment of the number-of-shares figures (as precise) and 
the price-per-share figures (as approximations).


> ...A financial statement assumes that the price per share is an exactly precise figure....

This is the same assertion. I believe that it is incorrect. If this 
premise is invalid, the rest of your argument does not follow.


> ...From the viewpoint of the financial world, in general, the price per share is the exactly precise figure....

This is the same assertion. I believe that it is incorrect. If this 
premise is invalid, the rest of your argument does not follow.


> ...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....
You are moving the goal posts. At the beginning of this thread, you were 
advocating that GnuCash change its arithmetic code, so that it would 
calculate different results. Now you are advocating that GnuCash change 
its documentation.  Better, but still based on a misunderstanding.


> 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...

There are many ways in which the GnuCash documentation could be 
improved. GnuCash is a project built largely of volunteer efforts. If 
you think it could be improved, the most useful contribution is to 
formally propose a change. See 
<https://wiki.gnucash.org/wiki/Contributing_to_GnuCash> to learn now.

But, a proposed change based on a misunderstanding will probably not 
succeed.


Bruce, why do you hold so fast to the conviction that the price number 
which the broker prints on the statement exactly represents the 
numerical value which they used in your transaction? I think that 
conviction is what keeping you from understanding the replies in this 
thread.

Best regards,
       —Jim DeLaHunt