Hieverybody,
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
New Business
============
The rational fraction you enter asinput is perfectly correct. Every
approximation introduces an error.In GnuCash's case, John says, "GnuCash's
number system usesrational numbers represented as the ratio of two 64-bit
integers;that allows a lot of precision but not infinite precision. Prices
maybe rounded to be representable. That's unlikely to have a materialeffect on
any calculation, unlike the rounding of quantities..."So, John says at least
two things. GnuCash approximates rationalnumbers and GnuCash's approximation is
not of infinite precision, butpretty close, compared to the other
approximations GnuCash uses inits internal calculations for quantities.
The following section addressesfour areas. Each area will tend to be addressed
in the order in whichit is mentioned in your post.
1. The rational fraction you enteras input is exactly correct.
2. TerryBoldt's asserts thatin processing the input data approximations may be
used. Is Terry'sassertion supported or not?
3. If approximations are not used,GnuCash needs no changes in precision. If
approximations are used, arelatively simple change could be implemented to
balance one's books.
4. I appreciate the care each ofyou has taken in reading and responding to
these posts.
On 2023-09-14 20:43:29EDT, JimDeLaHunt via gnucash-user wrote:
>Wait,you skipped a step. You have still not demonstrated that the
>currentimplementation is wrong. I believe that for securities
>transaction,GnuCash gives a result which is both correct (satisfies the
>equationrelating price, quantity, and amount) and precisely accurate
>(givesthe require numbers with zero difference from the true result).
Jeff Earickson noticed that GnuCashis occasionally not precise enough. He wants
his books to balance,but they don't.
Terrysays that on the occasions in which the computer is unable tocalculate
exactly correctly, he was forced to use an approximation.Once upon a time, it
was common to say, "Garbage in; garbageout." This phrase recognized that if one
entered nonsense datainto a computer it would produce, as a rule, nonsense on
output. Ofcourse, what we all hope is that if we enter exactly correct data,
asdone in this specific case, the computer will output data that isalso
correct. If this were not to be the case, can we imagine ourfeelings?
IfGnuCash is no longer using an approximation, then it is quitepossible that
GnuCash gives a result which is both correct andprecisely accurate?" If GnuCash
is still using an approximation,could it be that "GnuCash gives a result which
appears to beboth correct (almost all the time) and (very close to
being)precisely accurate?"
IfTerry's approximation, or a similar one, is still present in GnuCash.Would
one implication be that, on occasion, a user would find thatGnuCash has output
a result that is only very close to being exactlycorrect?
>Anyother arithmetic library dropped into GnuCash would give exactly the
>sameresult.
(Aside: Frankly, I'd like this tobe the case. If GnuCash were exactly precise,
then we would not haveto be concerned about any imprecision in it.)
GnuCash is among the programs thatneeds high precision in their calculations.
Other programmers havedeveloped approximations of greater precision to provide
theprecision needed for their calculations. For financial applications,decimal
libraries have been developed. Development occurred between2000, when Terry
wrote GnuCash, and 2003; development has onlyaccelerated in the two decades
since.
Could we ask, "If Terry'sapproximations are always precise enough, why did so
many people doso much work to improve their precision and why did they also
gothrough the additional effort to develop decimal libraries?" Ifwe did, one
might suppose that either they wasted their time andeffort or they had good
reasons to do the work.
Gnucash appears to be, to me, anexcellent program. I am impressed by all the
fine work that has beenand is being done on it. And I would like to use it.
GnuCash almost always calculatesfinancial information to the precision required
for work at hand. Inmy understanding of it, the incremental change under
consideration isthe difference between "excellent" and "perfect."For our
financial calculations precision, I'd say GnuCash isapproximately one smidgen
away from being perfectly suitable.
Of course, there are things I donot know about the proposed revision. Will the
programmers find itmore feasible to just increase the precision of the
calculations wenow have, will they be able to utilize the decimal
arithmeticlibraries easily? Since they are going to have to do the work,
I'dfavor letting them decide the specifics on how they wish to proceedto the
ultimate goal. However, as an intermediate solution, manualentry is relatively
simple to program and would be more immediatelyhelpful
>Ah, maybe now we are gettingsomewhere.
Bless you. You still hope I may beable eventually to explain things clearly.
>GnuCashdoes allow you to enter the exact value of $15.00 for the
>transactionamount. You do not need to enter a price. Have you tried
>thisin the GnuCash UI?
Yes, sir. I'll try to send you agraphic, FH B Test, showing it. In it, the
salient line shows a saleof 2.396 shares indicated by (2.396) in the Tot Shares
column. In theunlabeled Price Per Share column is 6 + 156/599. The Tot Sell
columnhas 15.00 representing the annual fee FH charged.
It is our pleasure to know that2.396 shares * (6 + 156/599) dollars/share =
$15.00. This equationdoes meet the requirement of "Logically,$value =
$price/share * #shares, and this should be preciseequality." There is absolute
certainty that the rational numberyou are entering into the computer is perfect
for the calculationrequired.
Abasic question this post is discussing is whether the computer isactually
calculating with the perfect number it was given or whetherit is actually
calculating with an approximation of the perfectnumber it was given.
Sofar we have two indications that the computer is usingapproximations.
1)Terry said so. (Could we ask the developers whether approximationsare still
used?)
2)Computers use arithmetic of base 2.
3)Display accuracy is very frequently, but not always, correct.
Figure9.21. Selling Shares for Gain Where the Sale and Gain are Recorded
inSeparate Transactions, in Transaction Journal View
>When you try to enter theexample transaction at hand..., you are probably
>using the stock transactionregister.
Ifonly I were that good. It is a mutual fund and I entered it into thestandard
transaction register. I'll implement your impliedsuggestion. Thank you for it.
Thetransaction does correspond to the transaction of Figure 9.21 for thedate of
03/221/2006. The line in the Action column of Figure 9.21labeled Sell shows
"Sell,Gross Sale 100 @ 36 = 3600, Assets:Brokerage Account:Stoc:AMZN, n,-100,
36, , 3,600.00." "Sell, ,Assets:Equity:MutualFund:FHB Test, n, (2.396), 6 +
156/599, , 15.00"was the corresponding line in the transaction register on my
machine.
>Guide[1]...TransactionJournal View"[3]...(Thesenumbers in square
>bracketsare footnotes to URLs. I put the full URLs at the bottom of
>themessage to make this part easier to read.)...Footnotes:...
Thankyou for both the formatting and the explanation. I felt your choiceswere
much clearer than mine.
>3. The line with account"Assets:Brokerage Account:Stock:AMZN" is the
>one with the UI which mattershere.
I agree with you.
>When you save the transaction,GnuCash will fill in the price for you.
I agree.
>What Isee it fill in is, "6+ 156/599".
My machine did the same thing thatyours did.
>This is equal to the rationalnumber 3750/599. We saw this number before,
>as the price which exactlyrelates 2.396 shares to the $15.00 transaction
>amount.
Yes, in this case both our machinesdisplay results accurate to the number of
significant digits shown.There is no doubt that this calculation, despite the
approximationTerry was forced to use, appears to be exactly correct. GnuCash
doesuse a very close approximation of the fraction, when it is unable
tocalculate using the exact fraction it was given as input. If GnuCashis still
using an approximation in its calculations and if Terry isan authoritative
source, what could we expect to see in this specificexample? If Terry's
approximation is relatively poor, we would seethe error. If his approximation
is relatively accurate, we would seeresults that equal the completely accurate
results. We would not seethe error.
These results do look like thecomputer did the calculation correctly. The
appearance of accuracyand precision is not in question in this specific
example.
So, either the computer actuallycalculates accurately or the approximation is
good enough, in thisexample, to display a result which appears to be accurate.
4-5) Rounding error, Commutation,respectively.
Rounding errors
Figure 9.10. The TransactionRegister Of The AMZN Account After The First
Purchase
>This UI is also explained inthe Tutorial and Guide, section 9.5 Buying
>Shares[4].
It is. For the 01/01/2005 entry inthe Action column, the row with Buy has the
following items: "Buy,, Assets:BrokerageAccount:Stock:AMZN, n, 100, 20,
2,000.00, ."
>It says there...to avoidrounding errors, it is better
>to automatically calculate*Price*
On Sun Feb 23 10:15:34 EST 2014,Mike Novack stepbystepfarm at mtdata.com
discussed a trade usingGnuCash 2.61. In the discussion, Jeff Earickson
concisely expressedhis feelings "1377.41 x 10.89 = $14,999.99 (one penny
off,arrrgh...)"[1].
He spent $15,000 to buy 1,377.41shares. He paid about$10.89000370260125
888442802070552703987919355892581003477541182364002003760681278631634734755809
81697/share. Were one to multiply1,377.41 shares by $10.89000370260125888442
80207055270398791935589258100347754118236400200376068127863163473475580981697/share,he
would get$14,999.99999999999999999999999999999999999999999999999999
99999999999999999999999999999999999999999999.
If $10.8900037... (compared to$10.89000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000)is not an error, why not?
If it is not a rounding error, whatkind of error is it?
If it is a rounding error, why doesGnuCash say, "to avoid rounding errors, it
is better toautomatically calculate *Price*?"
Commutation
In the discussion, Mike noted "ifA / B = C then B * C = A"[1].
In math, please correct me asnecessary, this property is called "Commutation."
Althoughit is not present in every numerical system, it is the commonly
useddefault practice.
Mike says, "In other words,you were assuming that if A / B = C then B * C = A
even when roundingis involved. Not true. Not necessarily exactly equal"[1].
If commutation is absent, what arethe implications?
If calculations are exactly precisecan one have a rounding error?
>Have you tried entering thisstock transaction without entering the
>price, and letting GnuCashcalculate it for you?
Yes. It calculates the price pershare as above in "3)Display accuracy is very
frequently correct."
>The stock transaction registerprovides exactly these data-entry
>fields. They are notread-only. Do you see, in your copy of GnuCash,
>something similar to the UIdepicted in Figure 9.21?
Yes. The stock transaction registerdoes provide exactly these data-entry
fields.
They are not read-only. I do see,in my copy of GnuCash, something similar to
the UI depicted in Figure9.21.
Thank you for pointing this out tome! This is exactly what we need -- three
data fields for Shares,Price, and Value which are not read-only.
I appreciate your familiarity withthe GnuCash user interface. Although I have
read the GnuCash helpdocumentation and Tutorial, you have assimilated the
information intoa useful fund of knowledge. I have not.
Were Jeff to have entered figuresfrom his brokerage statement, he might have
seen something similar tothe graphic below (Graphic 1).
Graphic 1.
Graphic 1 shows the RecalculationTransaction window. The first line says, "The
values entered forthis transaction are inconsistent. Which value would you like
to haverecalculated? Below that line are three lines with an initial
radiobutton followed by an instruction. Respectively they are Shares(Changed),
Price (Changed), and Value (Changed). At the right side ofthe last line there
are two choices -- "Cancel" and"Recalculate."
The developers would know thatthere is more to coding a manual solution than
adding a line belowthe Value (Changed) line, and setting a flag, but not too
much more,as coding goes.
The code ingnucash\register\ledger-core\split-register.c shows the following:
Code -- Start:
static int
recalc_message_box(SplitRegister* reg, gboolean shares_changed,
gboolean price_changed, gboolean value_changed)
{
intchoice;
int default_value;
GList* node;
GList* radio_list = NULL;
const char* title = _("RecalculateTransaction");
const char* message = _ ("Thevalues entered for this transaction "
"are inconsistent. Which value would you "
"like to have recalculated?");
if (shares_changed)
radio_list= g_list_append (radio_list, g_strdup_printf ("%s (%s)",
_("_Shares"),
_("Changed")));
else
radio_list= g_list_append (radio_list, g_strdup (_ ("_Shares")));
if (price_changed)
radio_list = g_list_append (radio_list, g_strdup_printf ("%s(%s)",
_ ("_Price"),
_("Changed")));
else
radio_list= g_list_append (radio_list, g_strdup (_ ("_Price")));
if (value_changed)
radio_list= g_list_append (radio_list, g_strdup_printf ("%s (%s)",
_("_Value"),
_("Changed")));
else
radio_list= g_list_append (radio_list, g_strdup (_ ("_Value")));
if (price_changed) default_value = 2; /* change the value */
else default_value = 1; /*change the value */
choice = gnc_choose_radio_option_dialog
(gnc_split_register_get_parent (reg),
title,
message,
_ ("_Recalculate"),
default_value,
radio_list);
for(node = radio_list; node; node = node->next)
g_free(node->data);
g_list_free (radio_list);
return choice;
}
End -- Code.
To accept the user's entries,adding another "if... else..." pair after the
"if(value_changed)..."statement, setting a flag, etc. would be a relatively
simple, interimsolution. If implemented, Jeff could enter 1,377.41 (Shares),
10.89(Price/share), and 15,000 (Value) into his machine, as seen inGraphic 1 in
the line labeled "Buy." The machine would savethose values. Jeff's books would
balance. Jeff would have no need toemail gnucash-users seeking a solution.
This is a possible interimsolution. A more permanent solution would await the
developers'further evaluation.
>have you read through all ofSection 9 of the Tutorial and Concepts
>Guide?
I have not read all of Section 9 ofthe Tutorial and Concepts Guide. Concerning
the areas of my currentinterests, I have copied the information from the Guide
to a documentand have added personal highlighting, underlining, and notes. I
havenot yet done this for Selling Shares, Dividends (including Return
ofCapital), and Splits and Mergers, since I do not need thatinformation, in
detail, at the moment. I have done similar things forthe other sections of the
Tutorial and Concepts Guide.
> Have you made a simple bookfor learning purposes, with made-up data
Yes. I have two types of referencesfor learning. One type is a general book. In
it the information isall in one file. The second type of reference has the
material forlearning located near the file in which it is needed. "FH BTest"
(v.s.) is one of the second type.
>and followed along with theexamples in the Guide?
Yes, but only if they were germaneto me.
In conclusion
=============
Jeff Earickson expected GnuCash tobalance his books, but it did not.
Your rational number input isperfect, but the computer isn't precise enough.
GnuCash can be made precise enoughto balance books.
A relatively simple change by thedevelopers is an interim solution.
The developers may consider aninterim and other, more precise solutions.
Footnotes:
[1]https://lists.gnucash.org/pipermail/gnucash-user/2014-February/053296.html,
https://lists.gnucash.org/pipermail/gnucash-user/2014-February/053299.html.
| | 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.
