Bruce:
Welcome to the gnucash-user email list! Hopefully we can give you some
useful answers. I will answer based on what I have heard developers say
on the list, and what I see in my stock transactions in GnuCash, though
I have not read the relevant GnuCash source code.
On 2023-08-21 10:21, Bruce McCoy via gnucash-user wrote:
...Could you please help me comprehend what ishappening in the
calculations of gnucash compared with thecalculations of Federated
Hermes? FederatedHermes determines the number of shares traded by the
currency amountof the trade divided by the price of the shares. For
example, onceupon a time they charged me a $15.00 Annual Fiduciary
Administrationfee. The share price was $6.26. To meet the fee they
sold 2.396shares and recorded it on their statement as -2.396 shares,
accurateto 1/1,000 of a share, for the transaction.....
It sounds like they charged you 2.396 shares to fulfil an obligation for
$15.00. They used the price of $6.26 to arrive at the amount of 2.396
shares, but it is not a fundamental part of the transaction. This is
important to how GnuCash records such transactions.
Logically, $value = $price/share * #shares, and this should be precise
equality. But is possible for a brokerage statement to report values
which do not have precise equality. It sounds like Federated Hermes
reported $15.00 = $6.26 * 2.396, but the actual $value of this $price
and #shares is $14.99896, a difference of $0.00104.
GnuCash takes the position that price is approximate and transient, but
currency received and paid, and shares received and issued, are exact
and persistent. Thus a GnuCash securities transaction stores the number
of shares and the currency value of the transaction, and derives the
price as $value/#shares. It stores the price as a rational number, a
ratio between numerator and denominator (i.e., a fraction). Thus it will
exactly satisfy the logical equation.
In your example, I expect GnuCash stored the price as , simplified to
3750/599 $/share.
As we see below thenumber of shares they reported was truncated from
the more accuratefigure given below. AnnualFiduciary Administrative
Fee of $15.00/Share price of $6.26 =2.3961661341853035143769968
05111821086261980830670926517571884984025559105431309904153354632587859425shares
traded. Ingnucash, entering the fee of $15 and the number of shares as
2.396,results in gnucash reducing the shares in the fund by 2.4,
changingthe fund and expense accounts by $15.02, and setting the trade
priceat $6.2583. Gnucashunderestimates the trade price by
(1-(6.2583/6.26))*100 = 0.02715 %. Gnucashcould use a longer fraction
to generate a more accurate share price. This only requires that the
fraction have more significant digits. If gnucash multiplied the
$15.00 fee by2.3961661341853035143769968051118
21086261980830670926517571884984025559105431309904153354632587859425shares,
won't the result be a share price of $6.26.
Please rethink this paragraph, treating the currency amount and number
of shares in the transaction as fundamental, and the price as a
byproduct. It would be something like, Annual Fiduciary Administrative
Fee of $15.00, #shares = 2.396, price = 15000/2396 = 3750/599 $/share.
In decimal terms, this is about $6.26043405676127/share. You might
describe it as, "the transaction price they reported was rounded from
the more accurate 3750/599".
I am interested by your statement, "results in gnucash reducing the
shares in the fund by 2.4". GnuCash is capable of storing share counts
to three decimal places. However, a setting in the Account window for
the security controls the number of decimal places GnuCash uses for that
security. See the Tutorial and Concepts Guide, 9.4.1. *Setup Accounts
for Stocks and Mutual
Funds*<https://www.gnucash.org/docs/v5/C/gnucash-guide/invest-setup1.html#invest-setup-stockaccounts2>.
See also Figure 9.8. *The “New Security” Window*, on that page.
For your security, what is the value for "fraction traded" in the
security window? It should be 1/1000 or smaller. What is the value for
"Smallest Fraction" in that dialogue box? It should be "Commodity Value".
Mutualfunds seem to treat both the amount of the local currency
tenderedand the price per share as decimal numbers of high precision
e.g.$15.0000000000000000000 or $6.260000000000000000000000. They seem
toconsider the number of shares traded as an approximation. Of
coursethey add and subtract fractional numbers of shares. Where do we
seethem dividing the transaction cost by the number of shares,
includingfractional shares, to calculate the the price per share?
Inevery mutual fund statement I have seen, the prices and the
numbersof shares always agree from month to month....
You just gave an example of a transaction where the price and number of
shares does not agree with the currency value of the transaction: $6.26
* 2.396 = $14.99896, not the stated value $15.00.
I would characterise this as, mutual funds seem to treat the amount of
the local currency tendered and the number of shares as decimal numbers
of exact precision, and the price as an approximation. Certainly, it
will help you understand GnuCash's recording of these transactions if
you think of it that way.
...Why do we not ...incorporat[e] more significant digits in the
calculations? InEdit > Preferences > Numbers, Date, Time > Numbers
>Force Prices to display as decimals, the maximum number of
decimalplaces one can display is only 8 (eight). If this is close to
thenumber of significant digits gnucash is currently using, could it
bethat we might consider using, instead of, say, double
binaryfloating-point method, a decimal floating-point arithmetic...
Note that you are talking about increasing the actual precision of
numbers used in calculation, but the spreadsheet preferences setting you
mention controls only the _display_ of numbers, not the actual precision
of the numbers.
GnuCash stores the price as rational numbers, which can have precisely
the correct value. Floating-point numbers, no matter the precision, will
always be approximations. A floating-point number cannot exactly store
the value of one-third (1/3), but a rational number can.
...Whydo we not avoid rounding errors? Why do we not enjoy the
accuracyand precision that everyone else can? Well, we can increase
theprecision of our calculations by increasing the number of
significantdigits in the decimal representations of our numerical
data. Bruce
From what you have presented, it looks to me like GnuCash has
sufficient precision to record your transactions. I suggest that path
forward is 1. to think differently about what is fundamental in these
transactions, and 2. to be sure that you have the security's "fraction
traded" set correctly in your books.
Does that help?
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.
