Charles Day wrote: > On Fri, Jul 4, 2008 at 12:48 PM, Christian Stimming <[EMAIL PROTECTED]> > wrote: > > >> Am Freitag, 4. Juli 2008 20:30 schrieb Charles Day: >> >>> On Fri, Jul 4, 2008 at 2:58 AM, Christian Stimming <[EMAIL PROTECTED]> >>> >> wrote: >> >>>> Am Freitag, 4. Juli 2008 04:31 schrieb Charles Day: >>>> >>>>> For reports, does anyone know why the calculation for price source >>>>> "weighted average" uses the absolute value in its calculations? It >>>>> seems to me that this gives incorrect results. >>>>> >>>> If I recall correctly, this code comes from the old days when I added >>>> this to >>>> track "my personal exchange rate" between USD and EUR. Without this >>>> >> code, >> >>>> I think if I bought x USD for y EUR and later sold x USD for y EUR, the >>>> resulting rate turned out zero instead of the expected value (which is >>>> >> x >> >>>> divided by y). Using absolute values here gave the intended results. >>>> >>> Ah, I see... so is the "weighted average" price source defined as >>> >> "weighted >> >>> average price experienced during buys and sells, not including >>> >> transaction >> >>> fees such as commission"? Because if so, then do you think that exchanges >>> with a zero "amount", such as capital gains and losses, should be >>> >> excluded? >> >> Indeed I introduced this option only with contexts in mind where there were >> no >> capital loss transactions are included. I have no idea how this has been >> used >> since then, or how other people have used it. >> >> >>> Example: Buy 5 USD for 4 EUR (exchange rate = 0.8), then sell 5 USD for 3 >>> EUR (exchange rate = 0.6), giving a 1 EUR capital loss. I am guessing >>> >> from >> >>> your response that would expect to see the weighted average price of the >>> buy and the sell alone, which is (4 + 3) / (5 + 5) = 0.7. >>> >> Exactly. That was what I intended when I introduced that option back in >> 2001. >> I didn't actually record any capital loss transactions. >> >> >>> However, the >>> current formula includes the capital loss in the calculation: (4 + 3 + 1) >>> >> / >> >>> (5 + 5 + 0) = 0.8. Of course, this assumes that you actually record the >>> capital loss. (GnuCash doesn't require you to, but failing to record the >>> loss puts the books out of balance.) >>> >>> Now on the other hand, what I am proposing is to get rid of the absolute >>> value but keep the zero "amount" exchanges. That would change the >>> definition to "weighted average cost for shares currently held, not >>> including transaction fees such as commission". A few users have been >>> asking for this option, which I maybe could add. >>> >> This option seems to make a lot of sense, too, but it will show different >> numbers. Hence I'm not sure whether a complete replacement of the existing >> option is the best idea, and maybe a new option is the better way to go. >> (Although adding yet another option is always the sub-optimum result of a >> discussion...) >> >> > > I think the version I am proposing would be useful, particularly for the > balance sheet, since it could show assets at cost (no unrealized gains). A > couple of users have said that this is the standard way of preparing > financials in India. One described it as not counting chickens before they > are hatched. I believe adding this option would close bugs 460721, 521403 > and 538800. > > As far as what to do with the current "weighted value" option, what do you > think? Replace it, or leave it in but modify it to leave out zero "amount" > splits? Do you want to make this decision? > > It is interesting to know your own personal exchange rate sometimes, but I > don't think it is a very useful way of valuing current holdings. For me it > would be more useful to revalue by "nearest in time" (comes from the price > DB) or "nearest exchange" (i.e. taking the exchange rate from the nearest > recorded trade - another option that doesn't exist at this point). > > -Charles >
A few years back (v1.8x), I had problems with these absolute values, and I patched report-utilities.scm,and commodity-utilites.scm so that the balance sheet would balance. In addition to completely removing all the numeric:abs, I also had to do something about the division by zero in commodity-utilities when there was a zero share balance. I'm using the "Nearest in Time" and the problem went away in the 2.x updates. If anyone's interested, I can dig up my old postings. Anyway, I vote for getting rid of absolute values in bookkeeping. -Dave > > >> Christian >> >> > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
