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
_______________________________________________
gnucash-user mailing list
gnucash-user@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.
