On Mon, Oct 6, 2014 at 8:57 PM, Nathan Grigg <[email protected]> wrote:
> > On Oct 6, 2014, at 3:58 PM, Martin Blais <[email protected]> wrote: > > On Mon, Oct 6, 2014 at 5:20 PM, Mike Charlton <[email protected]> wrote: > >> Thank you for posting this. Your second example explains weirdness that >> I was seeing but couldn't comprehend. >> >> So to put it succinctly, ledger balances as long as the rounded amounts >> balance. Perhaps I don't understand all of the nuances, but I have to say >> that I don't like that. If a transaction is off by a fraction of a cent, >> then that *does not balance* for me! >> > > Then you will never be able to balance anything that has a price or a > cost. There has to be rounding somewhere. > > > Strictly speaking, the price-adjustment option would be possible in > ledger, which uses rational numbers as internal representation, allowing > for exact balancing. But ledger is ill-equipped to solve this problem for > other reasons, for example, its lack of lot matching. > No this still doesn't work, there are many problems with it: - Precise representation requires that one of the numbers be left for the system to interpolate (you likely cannot even input the precise number by typing it, too many digits may be required). If you specify both cost and price, the mere fact that you're _typing_ decimal numbers implies a limited representation. - Secondly, precise representation is also not what you want: let's say we decide to make the cost (or price) the number slot we'll choose to represent exactly.... when it's time to calculate the capital gains you will be using that oddball precise cost (price) number to compute the dollar amount for the cost basis of the shares sold (which may not be the full original lot). The resulting number may include more precision than you want to have in order to compute the capital gains. The bank will compute... and the government will expect you to compute... using the recorded rounded price, not this weird "exact" price. Besides, the bank itself surely does not represent the cost with in a rational representation, so your calculation is _guaranteed_ to differ from the bank's own. This is why I've favored a small tolerance in balancing. Purists will think it's wrong, but if you think about the implications of using a precise representation and the associated complications it creates, it's actually better because it more closely matches what the banks/institutions do and does not lead to any of those problems. Finally, in practice, everyone uses the rounded amounts and ignores the rounding errors, and I feel that that's what we should do too: replicate what is used in practice, replicate the real world. (I do think that we can do better than the method I've implemented in Beancount, but I'm not sure yet what it is. I'm however convinced that using exact numbers is not the solution; inferring better or tighter rounding automatically might be a better direction.) Beancount could solve this by attaching a total cost to each inventory, in > addition to a per-share cost (with the stipulation that | total cost - > number * share cost | < tolerance). > This method breaks as soon as you split your lots (e.g. through the sale of a partial lot). (BTW maintaining the cost basis for the aggregate position is only elegant for an account maintained at average cost booking, where that's what one effectively does on every lot change. That minimizes numerical error.) > You still have to face the fact, however, that if you have three shares > worth $0.333 each, with a total cost to you of $1.00, and you sell these > one at a time at the same price but you receive $0.33 each, even though > their price has not changed, there is a penny that has disappeared. Is that > an expense due to rounding or a capital loss? Again, it doesn’t really > matter, but I feel like I should pick one. > You're supporting my point... it doesn't solve the problem. With my method you get to choose: you put the value you want on the cash side of the sale and as long as the difference is within tolerance (1.5c at the moment) you can replicate what your bank does. If you want 0.33, 0.33 and 0.34, you can do that and you actually end up with a better result than if you had used a precise representation. > > > I haven't decided whether or not having an elided expense account or >> simply reporting the exchange rate that was actually used is better. >> > > Note that an elided expense account effectively disables any balance > checks. > This is not a solution. > > > If it is built into the system, the elided expense account can also > balance check. That is, insert a ‘Expenses:Rounding’ transaction, but only > if the difference is less than some tolerance (and only if there is a > price/cost) > > The question is whether Expenses:Rounding is better than having the > ability to run a report listing all transactions which don’t quite balance, > so you feel good about your overall balance being out of whack. > I'll paraphrase to make sure I understand what you're proposing: you're proposing that some special account be defined and automatically inserted on transactions that don't balance exactly but _only_ in the cases where the difference is very small, say, below some tolerance (e.g., 1.5c like in Beancount), in order to silently swallow the rounding error and now we can force the balancing amounts to sum up exactly, knowing the rounding errors go somewhere. This is supposed to satisfy the user's conviction that transactions balance exactly... by padding them silently when they don't. Okay, it's definitely implementable and I'm not against the idea, but what's the point of doing this? Can we somehow use this rounding account for a particular purpose? How does it help the user with anything? Does it make our data entry and calculation work easier? If we're going to lose something to rounding and we won't be able to use it for anything, why even bother? > > Simon Michael: > > Correction: ledger reg liabilities. > > Yes, thanks. > > Nathan > > -- > > --- > You received this message because you are subscribed to the Google Groups > "Ledger" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "Ledger" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
