Sorry I didn't mean 1.5c in my email, rather 0.5c. Beancount's tolerance for balance amounts is 0.005 (not configurable at the moment, I can easily make this configurable).
On Mon, Oct 6, 2014 at 9:50 PM, Martin Blais <[email protected]> wrote: > 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.
