Hieverybody,
Congratulationson releasing GnuCash 5.4. You are doing excellent work. Thank you somuch. Sincethis is a relatively long post, there are summaries at each end. Thefirst section runs through "Old Business." The secondsection starts with "New Business." The third section isjust the attachment. To see the illustrations, please unzip theattachment,if present. Cordially, Bruce ExecutiveSummary ================= $Value= $Price-per-share * #Shares is the equation for discussion. Tobalance our books, we want that equation to be as precise aspossible. Sincecomputers calculate on base 2, they can not natively do decimalarithmetic. Althoughwe may expect exact precision, computers must use approximations. Inorder of simplicity and correctness, 3 solutions to increaseprecision are: 1)Manual correction 2)Approximations of greater precision, and 3)Decimal arithmetic. Jim, You are right. Twice I did notanswer one of your questions. I apologize. I'll respond to it first,as it is an "Old Business:"item. As a newcomer to GnuCash, one ofthe problems that I have is that I do not know a lot of things whichyou experienced people take for granted. For example, until a fewdays ago, I missed the contributions Ken Farley, John Ralls, and StanBrown made on Saturday, September 9th. Had I known how to communicateon GnuCash better, I would have responded more promptly. I apologizefor my error and will respond to you under Old Business. Thank youfor helping me understand how GnuCash works. Another thing that I have notfigured out is how to maintain spaces separating words when I post onGnuCash. I'll try a mono-spaced font to see if that helps. If it doesnot help, I'd appreciate your suggestions. On Sun Feb 23 10:15:34 EST 2014,Mike Novack mentioned Jeff Earickson's comment "1377.41 x 10.89= $14,999.99 (one penny off, arrrgh...)"[1].Jeff seems to want GnuCash to calculate the value of his accountcorrectly. What evaluation will we place on Jeff's feelings? What is our position? Are we goingto say, "We want GnuCash to be as imprecise as it is currently?"Or are we going to say, "We want GnuCash to be as precise ascurrent practices allow?" Will we, if it is possible, accept thechallenge of making VALUE more accurate? Wait, is it possible for VALUE tobe more precise? A rational number, say 1/3, is exactly precise. Whenwe enter the rational number into a computer, our initial, workingassumption is usually that the machine will accurately compute aprecisely correct answer. Is this initial assumption correct orfalse? "0" or "1" arethe values our computers have to store data. Computers therefore mustdo arithmetic using a base of 2. Decimal arithmetic (base 10) isnatively impossible for them. Our computers are forced to approximatemany of the values we give them. If the approximations are notprecise enough, we (GnuCash users) will, on occasion, notice theerrors the computer is making. Our current example person is JeffEarickson. This thread is to help Jeff and the other people usingGnuCash to get more precise results so that their books balance "tothe penny." Old Business ============ 1. Jim DeLaHunt --------------- On 2023-09-09 13:05, Jim DeLaHuntwrote: > This would be a greatopportunity for you to answerthe questionI repeated to you last message: I certainly agree. That was mymistake. > But I see you skipped over itagain. I certainly did. Thank you forgiving me another chance. >1. if your brokerage reports a transaction in terms of price,currency > received and paid, and shares received andissued, which are logically > inconsistent, how should youinterpret that information? This is a > step you have totake before entering the transaction into your >bookkeeping. Iagree, "If a brokerage reports a logically inconsistenttransaction, before entering that transaction into a ledger, oneshould carefully interpret the inconsistency." What is themagnitude of the inconsistencies under discussion? TerryBoldt wrote "The division operation is done in 'double' since Ido not think that anybody really wants (9 / 2) to equal 4 instead of4.5 for financial operations." FederatedHermes (FH) has not sentme something similar to "You sent us a purchase order of $9.00to buy a stock now priced at $2.00/share, so we increased yourholdings by 4 shares (1 significant figure). We are not charging youany commission. You get no change." Had that type of notice beensent, I'd change brokers. Terrymentions the term "double." My current understanding of theterm is "double" is an abbreviated reference to "doubleprecision" calculation and "double" offers moreprecision then "single precision" calculation. When Terrywrites "since I do not think that anybody really wants (9 / 2)to equal 4 instead of 4.5 for financial operations," he is, ineffect, saying that, when dividing, the computer is not always usingthe fraction entered as input, but instead is sometimes using only anapproximation of the fraction. Since Terry feels that the "standardprecision" (also called "float.") calculation methodis too inexact an approximation for financial work, he decided to usea more exact approximation of the input fraction where necessary. Hissolution was to choose to use "double precision"calculation to obtain a more precise result when the computer isunable to calculate the fraction entered as input exactly. Terry and his colleagues, ofcourse, knew that the computer, using mathematical operations with abase of two (2) instead of ten (10), in calculating some fractions,was only using an approximation and that especially in fields likefinance and engineering the approximation that the computer was usingto calculate the result was not precise enough for the work it wasbeing asked to do. So, computer programmers developed a process whichmight yield a yet greater level of precision. They called it "longdouble" precision calculation. A "long double"precision calculation offered the chance of greater precision thanthe "double" precision calculation. Searching the source code for thestring "long double" yielded no results. This may mean thatGnuCash is still using the "double precision calculationprogrammed by Terry. In any event, it seems that GnuCash is able,when it can only estimate the value of the fraction it is given toevaluate, to estimate results with a precision frequently of about 10significant digits. So, the differences underdiscussion in GnuCash are not at the level of, say, 1 or 2significant digits, but are orders of magnitude smaller. How shouldwe interpret this information. In our case the input fraction isperfect. Since it is perfectly precise already, the precision can notbe improved. Since computers calculate using a base of two (2),sometimes they are forced to approximate certain fractions. Ourfraction of interest, 3750/599, is one of the fractions that thecomputer is unable to calculate exactly, so it has to use anapproximation of the fraction in its calculation. In this situation, the computerbeing able to only very closely approximating the correct answer,changing brokers is not the answer. We have at least three options.One is to use a more accurate approximation. A second is to somethinglike decimal arithmetic. A third is to manually enter the appropriatevalue. 2. Ken Farley -------------- On 2023-09-09 15:19:53EDT, Ken Farleywrote: >The key equation is AMOUNT =PRICE * SHARES >Gnucash works under thephilosophy that two of those terms must be >maintained precisely: You are quite correct. This is howGnuCash is constructed. >What I really care about whenI get my statements from investment >institutions, or tradenotifications, is the number of SHARES involved >and the total cost to me. Yes, when you get your statementsfrom investment institutions, or trade notifications, the number ofSHARES involved will be more precise than it is now and the totalcost to you will also be more precise. There will be even betteragreement between the GnuCash results and those of your otherstatements and notifications. 3. John Ralls -------------- On 2023-09-09 15:36:40 EDT, JohnRalls wrote: >Amount is the quantity of asplit in the split account's commodity. >Value is that amount convertedto the transaction currency, which in turn >is determined by the accountregister in which the transaction is >created. If that account isdenominated in a non-currency commodity then >it takes the currency of thenearest parent account that is denominated >in a currency. >Price is the ratio between thetwo. Thank you for your clearexplanation. >Commodities...have minimumfractions. I did not know that. Thank you fortelling me. >Financial quantities arealways rounded to that minimum fraction. GnuCash >followsthat practice. You understand that GnuCash usesapproximations. >GnuCash's number system usesrational numbers represented as the ratio >of two 64-bit integers; thatallows a lot of precision but not infinite >precision. Prices may berounded to be representable. That's unlikely >to have a material effect onany calculation, unlike the rounding of >quantities, though for that tobe true GnuCash has to limit the minimum >fraction of a commodity to10^-9. I do not know the precision of theratio of two 64-bit integers in approximating rational numbers. Butyou know that GnuCash's approximations of rational numbers is muchmore precise than GnuCash's approximations of quantities. So, thereis the possibility that GnuCash's approximations of quantities couldbe significantly improved, were there a way to do it. I do not understand theimplications of your statement "...GnuCash has to limit theminimum fraction of a commodity to 10^-9." Could you elaborateon this, at least, either in terms of the number of significantdigits or in terms of the precision of the decimal portion ofrational number fractions. >"So the claim value =price * shares is logically correct but depends on >price * shares yielding alegal value in value's currency; the reverse >is true as well: shares =value/price is true only if value/price >produces an amountrepresentable in the share commodity's minimum >fraction." OK. Good to know. >The consequence of thatrounding is that you should generally tell >GnuCash the amount and valueand let it calculate the price to ensure >that GnuCash matches whateverrounding got appliedat your financial >institution. Yes. Jeff Earickson enters Price *Shares to generate Value. In Jeff's case, Value, when compared toJeff's financial institution's statement, is incorrect by $.01. ForJeff's case, our goal is to increase GnuCash's precision by one centout of 1,499,999 cents. If we do that, GnuCash's result and Jeff'sfinancial institution's statement will agree. Jeff's books willbalance. 4. Stan Brown ------------- On 2023-09-09 15:41:46EDT, Stan Brown wrote: >Well said, Ken! Agreed. >It is _mathematically_ notpossible to have three decimal numbers A B >and C, each rounded to adesired number of decimal places, fulfill the >equation A * B = C exactly.For some particular numbers A and B, to >some suitable number ofdecimal places, it will indeed work out, but >the general case ismathematically impossible. Agreed. Well said, Stan! >Numberof shares and total amount must be exact to the generally >acceptednumbers of decimal places, or people's books won't >balance. Agreed. Very well said, Stan! Wewant the number of shares and total amount to bet be exact to thegenerally accepted numbers of decimal places, so that people's bookswill balance. We want both Jeff's books and the books of all theother GnuCash users, in addition to having the number of shares becorrect, to balance to the penny. Ken, John, and Stan thank you bothfor your concern about GnuCash and for your kindness in providinginsights. I appreciate each them and each of you. | | Virus-free.www.avast.com | _______________________________________________ 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.
