How timely we've just had this discussion: I completed a script that
generates a fake user with a fair amount of detail, and as I'm now writing
a script to convert Beancount syntax to Ledger format, the precision issue
is biting me. Here's a problematic example with how Ledger does its
precision tracking (simplified after removing a lot of other stuff around
it).
Consider the following two transactions:
2012-07-09 * Investing 60% of cash in RGAGX
Assets:US:Vanguard:RGAGX
3.15 RGAGX {114.28 USD}
Assets:US:Vanguard:Cash
-359.98 USD
2012-07-23 * Investing 40% of cash in VBMPX
Assets:US:Vanguard:VBMPX
1.128000000000 VBMPX {70.95 USD}
Assets:US:Vanguard:Cash
-80.03 USD
Running Ledger on this works fine:
ledger -f /tmp/after.lgr bal --no-color
3.15 RGAGX
-440.01 USD
1.128000000000 VBMPX Assets:US:Vanguard
-440.01 USD Cash
3.15 RGAGX RGAGX
1.128000000000 VBMPX VBMPX
--------------------
3.15 RGAGX
-440.01 USD
1.128000000000 VBMPX
However, now insert another, unrelated transaction, one that "resets" the
precision of USD in-between, like this:
2012-07-09 * Investing 60% of cash in RGAGX
Assets:US:Vanguard:RGAGX
3.15 RGAGX {114.28 USD}
Assets:US:Vanguard:Cash
-359.98 USD
2012-07-16 * ;; Tag: #trip-new-york-2012 Takahachi |
Liabilities:US:Chase:Slate
-46.833955603895 USD
Expenses:Food:Restaurant
46.833955603895 USD
2012-07-23 * Investing 40% of cash in VBMPX
Assets:US:Vanguard:VBMPX
1.128000000000 VBMPX {70.95 USD}
Assets:US:Vanguard:Cash
-80.03 USD
Now this does not balance anymore! :
ledger -f /tmp/after.lgr bal --no-color
While parsing file "/tmp/after.lgr", line 11:
While balancing transaction from "/tmp/after.lgr", lines 9-11:
> 2012-07-23 * Investing 40% of cash in VBMPX
> Assets:US:Vanguard:VBMPX
1.128000000000 VBMPX {70.95 USD}
> Assets:US:Vanguard:Cash
-80.03 USD
Unbalanced remainder is:
0.001600000000 USD
Amount to balance against:
80.031600000000 USD
Error: Transaction does not balance
(Yes, the intervening transaction's precision from my incomplete script as
I was developing it, but it doesn't matter, you can easily imagine a real
scenario where this would happen.)
This is in-line with my suspicion: precision must either be set once and
_globally_, or inferred automatically _locally_.
(I'm not sure how I will patch things up.)
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
>
> 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.
