FYI, for those reading the thread later in history: Many of the ideas discussed in this thread have been implemented. See details here: http://furius.ca/beancount/doc/tolerances http://furius.ca/beancount/doc/proposal-rounding
On Tuesday, October 7, 2014 at 2:12:25 PM UTC-4, Martin Blais wrote: > > On Tue, Oct 7, 2014 at 12:03 PM, Nathan Grigg <[email protected]> > wrote: > >> >> On Oct 6, 2014, at 9:46 PM, Martin Blais <[email protected]> wrote: >> >> On Mon, Oct 6, 2014 at 10:57 PM, Nathan Grigg <[email protected]> >> wrote: >> >>> On Oct 6, 2014, at 8:30 PM, Martin Blais <[email protected]> wrote: >>> >>> I like the idea that the tolerance can be inferred automatically from >>> the smallest digit in the input instead of using a fixed value. I should >>> implement that in Beancount as well, there's no reason it couldn't do >>> it.This should be a very easy change to make. >>> >>> At the moment Beancount uses "0.005" regardless of unit... this is a >>> known pending issue (I don't have any Japanese users yet I suppose). I've >>> been thinking that a per-commodity tolerance could be selected instead, >>> i.e., a map of commodity to tolerance value, but while better, this is also >>> unsatisfying. >>> >>> I wonder if inferring like Ledger works in all cases though; consider >>> this case: >>> >>> Assets:Fidelity:Fund 11.27534 FUND {1.2357 USD} >>> Assets:Fidelity:Cash -13.93 USD >>> >>> The precise cash amount is 13.932937638 USD. >>> How many digits should this use? >>> >>> >>> Ledger would infer 2 digits of precision for USD and 5 for FUND. The >>> price portion does not affect precision. Ledger also has a D directive to >>> specify the minimum precision per currency. >>> >> >> I'm not sure what that means... there is no need for any precision on >> units of FUND, the balance amount of that leg is in USD calculated as >> 11.27534 x 1.2357. In USD. The balance residual is 11.27534 x 1.2357 + >> -13.93. The only precision that matters is that of USD. >> >> Does it use the precision inferred on units of FUND in any way? >> If so, how? >> >> >> In Ledger, the precision is not per-transaction, but file-wide. (Because >> Ledger process the file in one pass, this means that the precision may >> increase, but never decrease, as it processes the file.) So Ledger would >> infer from this posting that FUND should always be measured and displayed >> to 5 digits of precision (or at least from now on). >> >> Which brings up an interesting option for inferring the precision: the >> maximum number of digits from all legs without cost/price conversions. And >> this should be calculated for each group of postings whose "balance >> amounts" are in a common commodity. That sounds right to me. >> >> >>> >>> The debited cash is 13.93, this would be the _actual_ amount debited by >>> the fund manager, so it can't be anything else. >>> In this example, I would argue that you would want the _minimum_ number >>> of digits to be used. >>> (But certainly not the minimum if you're using an integer number of >>> shares...) >>> >>> If we can come up with a rule that works well in all cases I'll >>> implement it. >>> >>> >>> To be honest, I would prefer to explicitly specify precision, although >>> this makes it harder to work correctly "out of the box". >>> >> >> Why? Because you fear not having a minimum will create pathological cases >> where a user will insert a balance against an integer number of dollars and >> make a mistake on the cost that will go undetected? >> >> 2014-09-09 * >> Assets:Invesments ... >> Assets:Cash -1000 USD >> >> Just curious. What cases do you see as problematic? >> >> >> I don’t have anything particular in mind. I just like having control. But >> I don’t feel strongly here. >> >> I hadn’t considered per-transaction precision, but if you go that route, >> one thing you will need to think about in that case is what to do for this: >> >> 2014-09-09 * >> Assets:Invesments 5 FUND @ $2.50233 >> Assets:Cash >> >> > (You're missing the USD, I'll assume it there after 2.50233) > > Yes, indeed. It would need to be rounded at some level of precision. > I'm a bit reluctant to define a mapping of {commodity: precision} because > for the same commodity, a different precision maybe required per account. > > Note that one I could do is delay elided postings interpolation (I have to > do that for another feature anyhow) and then run an analysis on each > account, and take the dominant mode of the precisions, in this example, > that would mean "look at precision of all the explicit amounts on > Assets:Cash for USD and choose the most appropriate precision" and then > round at that. > > Hmmm this will require a bit more thought. > > > -- --- 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.
