Tolerances and balances

[Eric Altendorf]

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}
  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.  I've tried both the "inferred_tolerance_default" option and the "Explicit Tolerances on Balance Assertions" (e.g., "~ 0.00001 ABC").

thanks,

eric

[Daniele Nicolodi]

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.

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

Cheers,
Dan

[Eric Altendorf]

On Wed, Jul 19, 2023 at 11:54 AM Daniele Nicolodi <dan...@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