Bruce, I don't know who this "Jim" is, their replies are not making it to the list. Unfortunately their understanding of GnuCash's handling of amount, value, and price is flawed.
Amount is the quantity of a split in the split account's commodity. Value is that amount converted to the transaction currency, which in turn is determined by the account register in which the transaction is created. If that account is denominated in a non-currency commodity then it takes the currency of the nearest parent account that is denominated in a currency. Price is the ratio between the two. Commodities, both currency and otherwise, have minimum fractions. For example there is no such thing as a fraction of a car, a tenth of a Japanese Yen, or one thousandth of a US Dollar. Financial quantities are always rounded to that minimum fraction. GnuCash follows that practice. GnuCash's number system uses rational numbers represented as the ratio of two 64-bit integers; that allows a lot of precision but not infinite precision. Prices may be rounded to be representable. That's unlikely to have a material effect on any calculation, unlike the rounding of quantities, though for that to be true GnuCash has to limit the minimum fraction of a commodity to 10^-9, otherwise it's possible to have unrepresentable prices in highly inflated currencies. 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. The consequence of that rounding is that you should generally tell GnuCash the amount and value and let it calculate the price to ensure that GnuCash matches whatever rounding got applied at your financial institution. Regards, John Ralls > On Sep 9, 2023, at 10:59, Bruce McCoy via gnucash-user > <gnucash-user@gnucash.org> wrote: > > Jim, > > Thank you for your response of Mon, Aug 21, 2023 at 5:00 PM via GnuCash-user. > In it you said: > > "Logically, $value = $price/share * #shares, and this should be > precise equality." > > This is certainly true. And accuracy is a top consideration in a financial > program. > > GnuCash "...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." > > It is also certainly true that this way of storing a value as a rational > number is both excellent and exact. Our desire is to exactly satisfy the > logical equation. > > "he actual $value of this $price and #shares is $14.99896, a > difference of $0.00104." > > At the moment, using these figures, GnuCash is (14.99896/15.0000000) * 100 = > 99.993066666666666... % correct. GnuCash is currently doing well. The > incremental change needed is small. This should encourage us. This is our > major point for discussion. Please allow me to discuss it in detail in a > later post. > > For the moment, let's discuss a minor point. > > "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..." > > In this minor point, the viewpoint that the smallest units of currency are > considered exact both by governments and their financial companies will be > investigated. One conclusion will be that GnuCash should consider "price" > and "currency received" as exact figures. A second is that GnuCash should > consider "shares received and issued" as an approximation, although it is not > always true. The details are discussed next. > > It is true that GnuCash treats the number of shares received and issued as > exact and persistent quantities. If someone were to ask us whether the way > GnuCash treats the currency pricing is either "approximate and transient" in > the case of $6.26 per share or "exact and persistent" in the case of the > $15.00 annual account fee, what could our answer be? Buying one share will > cost 626 pennies. The annual fee is 1,500 pennies. Other than the quantity > of them, what is the essential difference in the pennies used to purchase a > share and the pennies used to pay the fee? > > If we can show a difference in the pennies of one groups compared with the > pennies in the second group, then we could maintain that one group could > consist of pennies that are "approximate and transient" and the other group > of pennies are "exact and persistent." What distinction could we make? We > could say "GnuCash takes the position that price is approximate and > transient, but currency received and paid, and shares received and issued, > are exact and persistent." Essentially that is how we have always considered > the matter. > > Is "We have always done it this way." a compelling response? If we look at > our general situations as human beings over the course of the centuries, are > we living our lives with, for example, many different technologies than our > ancestors used? If we looked at the specific cast of GnuCash itself, do we > see features being added and defects being removed? From both the general > and the specific examples, is "We have always done it this way." a > compelling response? If so, we might continue as we have up to now. If not, > we might consider a change. > > If we are going to continue as GnuCash has up to now, we have to show the > essential difference in the pennies used to purchase a share and the pennies > used to pay the fee. As I fail to see an essential difference between the > pennies in one group compared with the pennies in the other group, if someone > were to ask me to explain why GnuCash holds the position it does in this > matter, I would not know how to respond. > > In double-entry financial transactions involving the smallest units of the > same currency at the same time, when are the units of one side of the > transaction given different values than the units on the other side of the > transaction? I fail to remember any. > > If we can not demonstrate an essential difference between the two groups of > pennies, how can it be clear that they are different? If they are not > different, they have to be the same. Both values have to be either > "approximate" or "exact." If they are approximate, how do we distinguish > that from their exact value? If they are exact, then when we divide the fee > of 1,500 pennies by 626 pennies per share we may get an approximation of the > number of shares purchased. > > In this latest case, the currency values are considered to be exact and the > transaction concerning the number of shares involved, although it, on > occasion, may be exact, may frequently be an approximation. > > In conclusion, GnuCash, through a simple change, would be improved by more > logical consistency. It is more consistent to consider the currency values > to be exact, and let any approximation be in the shares traded. > > Thank you for reading this. Please let me know which areas are unclear, > incorrect or both. > > Best Regards, > Bruce > > > > _______________________________________________ > 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. _______________________________________________ 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.
