On Wed, Jul 19, 2023 at 11:54 AM Daniele Nicolodi <dani...@grinta.net>
wrote:
> On 19/07/23 00:12, Eric Altendorf wrote:
> > I seem to not understand how tolerances are used. I have this beancount:
> >
> > 1 2018-01-01 open Assets:Alpha:ABC ABC
> > 2 2018-01-01 open Assets:Beta:ABC ABC
> > 3
> > 4 2018-01-02 * "synthesize a position with zero cost basis"
> > 5 Assets:Alpha:ABC 1.0 ABC {0.00 USD}
>
> This is not a valid transaction. All transactions needs to have at least
> two postings. It is a fundamental requirement of double entry accounting.
>
I thought the requirement was merely that the transaction balances to
zero. FWIW, bean-check doesn't seem to throw an error on this transaction,
although it does if I change the cost to be non-zero, since then it doesn't
balance. I guess it's fair to say this is a degenerate transaction and not
a very accounting-ish way to initialize an account, point taken, I was just
hacking something together to test tolerances :)
> 6
> > 7 2018-01-03 balance Assets:Alpha:ABC 1.0 ABC ;; Assertion passes
> > 8
> > 9 2018-01-04 * "Transfer from alpha to beta"
> > 10 Assets:Alpha:ABC -0.1 ABC
> > 11 Assets:Beta:ABC 0.1 ABC
> > 12
> > 13 2018-01-05 balance Assets:Alpha:ABC 1.0 ABC ;; Does not fail!
> > 14
> > 15 2018-01-06 * "Transfer from alpha to beta"
> > 16 Assets:Alpha:ABC -0.5 ABC
> > 17 Assets:Beta:ABC 0.5 ABC
> > 18
> > 19 2018-01-07 balance Assets:Alpha:ABC 1.0 ABC ;; Does fail.
> >
> > I can't get the balance assertion on line 13 to fail.
>
> This is because the inferred tolerance on the ABC commodity is 0.1. If
> you want the tolerance inference algorithm to infer a lower tolerance,
> you need to write your numbers with more decimal digits. If you write
> them with two decimal digits, the balance assertion correctly fails.
>
I see. This is very surprising to me. I mean, I understand making the
assertions adapt to the precision the user is actually using, but this
seems too loose. If I'm using one digit of precision past the decimal
point, then ... why would 0.9 equal 1.0?
To make it more realistic, if I'm working with USD and expressing my values
to the US cent, then I would want my balance assertions to be correct to
the nearest cent. If they're off by *strictly* less than a cent, OK, but a
discrepancy of a full cent I would want flagged, no?
I tried a decimal point in the other direction; if I operate with integers,
start with 10 ABC, the reduce 1 ABC, and assert a balance of 10 ABC, it
*does* correctly fail (since 9 is not 10), which seems inconsistent with
the behavior of the digits right of the decimal point...
> I've tried both
> > the "inferred_tolerance_default" option and the "Explicit Tolerances on
> > Balance Assertions" (e.g., "~ 0.00001 ABC").
>
> How did you test this? Specifying an explicitly tolerance correctly
> triggers the balance assertion for me. "inferred_tolerance_default" is
> not relevant here because the ledger contains enough data to derive a
> tolerance (although it is not the one you expect).
>
I can't reproduce this, so I think I must have made a mistake in my earlier
experiment, sorry for the noise.
Best,
Eric
--
You received this message because you are subscribed to the Google Groups
"Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beancount+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beancount/CAFXPr0us838kAPUxgHV-91YygxBQfYJHn6u06cxrXFr%2BhBx%3DSA%40mail.gmail.com.
