strange behaviour with included files

56 views
Skip to first unread message

François

unread,
Nov 15, 2020, 12:26:05 PM11/15/20
to bean...@googlegroups.com
Hello,

There is some strange behaviour with include directive.

For example with those two files

cat <<EOF >example.beancount
1970-01-01 open Expenses:MyExpense
1970-01-01 open Assets:MyAccount

1970-01-02 *
Expenses:MyExpense 1000.00 EUR
Assets:MyAccount -1000.00 EUR

1970-01-02 * "Verif "
Expenses:MyExpense 333.0000000000000182076576039 EUR
Assets:MyAccount -333.0000000000000182076576039 EUR
EOF

cat <<EOF >example_with_include.beancount
include "example.beancount"
EOF

The results differ when we use the include file or not.

In the case without include (bean-query example.beancount 'SELECT *')
I have a stack trace with this error
decimal.InvalidOperation: [<class 'decimal.InvalidOperation'>]


In the case with include I have an output

$ bean-query example_with_include.beancount 'SELECT *'
date f narrat position
---------- - - ------ -----------------------------------
1970-01-02 * 1000.00 EUR
1970-01-02 * -1000.00 EUR
1970-01-02 * Verif 333.0000000000000182076576039 EUR
1970-01-02 * Verif -333.0000000000000182076576039 EUR






I stumbled on this while splitting some beancount ledger on multiple
files. In my case the transaction with a lot of decimal is generated by
a plugin which makes some division of existing postings to split them
between several accounts.
dest_amount=core.amount.mul(original_posting.units, core.number.D(1/3))

In this case I have the following outputs :

$ bean-query exPlugin.beancount 'SELECT * WHERE account ~ ":A"'
date f narrat position
---------- - - ------ ----------
1970-01-02 * Verif 333.33 EUR

$ bean-query exPlugin_with_include.beancount 'SELECT * WHERE account ~ ":A"'
date f narrat position
---------- - - ------ ---------------------------------
1970-01-02 * Verif 333.3333333333333148296162562 EUR


The directive are exactly the same in both cases. The only change is
that in the first case I have only one file and in the second case I
have the transaction in an included file.

I like more the first version (with proper rounding) but what triggers
me is the lack of coherence.


Have you any explanation or workaround about this ?


I use Beancount 2.2.3+hg20200223.0.3af921a

François

Martin Blais

unread,
Nov 25, 2020, 1:57:52 AM11/25/20
to Beancount
This is a bug.
Here's why this happens:
The error condition described in this method is hit:

"Unlike other operations, if the length of the coefficient after the quantize operation would be greater than precision, then an InvalidOperation is signaled. This guarantees that, unless there is an error condition, the quantized exponent is always equal to that of the right-hand operand."

What's happening is that the precision automatically inferred from the numbers you've provided (the ones with the large fraction) exceed that of the context.
e.g. with this patch it runs:
bergamot [git|v2]:~/p/beancount$ git diff
diff --git a/beancount/core/display_context.py b/beancount/core/display_context.py
index cfed0188..9a9dbfce 100644
--- a/beancount/core/display_context.py
+++ b/beancount/core/display_context.py
@@ -217,6 +217,10 @@ class DisplayContext:
             # Note: We could probably logging.warn() this situation here.
             return number
         qdigit = Decimal(1).scaleb(-num_fractional_digits)
+
+        import decimal; decimal.getcontext().prec = 30
+        print("XXX", qdigit, decimal.getcontext().prec)
+
         return number.quantize(qdigit)


I'll have to find a solution.





--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/20201115172254.7xtksqidbiwp2kjd%40fjo-extia-HPdeb.example.avalenn.eu.

Martin Blais

unread,
Nov 25, 2020, 10:22:13 AM11/25/20
to Martin Blais, Beancount

François

unread,
Dec 2, 2020, 2:31:16 PM12/2/20
to bean...@googlegroups.com
Thank you for having a look at it.
I will follow the issue on github.

On Wed, Nov 25, 2020 at 10:21:53AM -0500, Martin Blais wrote:
> https://github.com/beancount/beancount/issues/584
>
> On Wed, Nov 25, 2020 at 1:57 AM Martin Blais <bl...@furius.ca> wrote:
>
> > This is a bug.

Martin Blais

unread,
Dec 2, 2020, 3:52:58 PM12/2/20
to Beancount
It's already fixed.

--
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+...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages