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 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.
