Debugging display contexts

[Eric Altendorf]

I don't mind excessive decimal points in my bookkeeping but I'd like to be able to render reports and control the reported precision there.  So I implemented __round__() on Amount, and added Amount to the signature of the bean-query round() function in query_env.py (happy to offer PRs after I am sure it's correct).

The round() function now works for me in bean-query, and some debugging confirms that internally the Amount number gets rounded, but for some reason the DisplayContext still seems to get the idea my numbers have lots of points of precision.  If I wrap the round() with a str() to force an early conversion to a string, one can see that the numbers have been rounded as expected.  Compare:

beanquery> SELECT date, maxwidth(narration, 20), account, 10, round(cost(position), 4) as amount FROM has_account("PnL") AND year(date) = 2021 WHERE account="Income:PnL" AND abs(number) < 100 limit 5
   date     maxwidth(narration   account    10               amount            
----------  ------------------  ----------  --  --------------------------------
2021-05-10  Send 0.0001 XCH     Income:PnL  10  -0.1000000000000000000000000 USD
2021-08-31  Fees for Buy [...]  Income:PnL  10   5.3300000000000000000000000 USD
2021-08-31  Fees for Buy [...]  Income:PnL  10   5.3300000000000000000000000 USD
2021-08-31  Fees for Buy [...]  Income:PnL  10   7.4600000000000000000000000 USD
2021-09-03  Fees for Buy [...]  Income:PnL  10   1.6800000000000000000000000 USD

beanquery> SELECT date, maxwidth(narration, 20), account, 10, str(round(cost(position), 4)) as amount FROM has_account("PnL") AND year(date) = 2021 WHERE account="Income:PnL" AND abs(number) < 100 limit 5
   date     maxwidth(narration   account    10     amount  
----------  ------------------  ----------  --  -----------
2021-05-10  Send 0.0001 XCH     Income:PnL  10  -0.1000 USD
2021-08-31  Fees for Buy [...]  Income:PnL  10  5.3300 USD
2021-08-31  Fees for Buy [...]  Income:PnL  10  5.3300 USD
2021-08-31  Fees for Buy [...]  Income:PnL  10  7.4600 USD
2021-09-03  Fees for Buy [...]  Income:PnL  10  1.6800 USD 

I've dug around the DisplayContext updating code and can't figure out what's going on.  Any ideas?

eric

[Daniele Nicolodi]

On 10/08/23 06:43, Eric Altendorf wrote:
> beanquery> SELECT
> date > maxwidth(narration, 20),

> account,
> 10,
> round(cost(position), 4) as amount
> FROM > has_account("PnL") AND
> year(date) = 2021
> WHERE

> account = "Income:PnL" AND > abs(number) < 100
> LIMIT 5

Why do you filter by account twice?

> I've dug around the DisplayContext updating code and can't figure out
> what's going on.  Any ideas?

The number of decimal digits used to represent amounts is determined by
the content of the ledger at parsing time, not by the data values in the
column.

The algorithm used to determine the number of decimal digits to use
looks at the statistical distribution of the number of digits in all the
numeric values used paired with a given currency.

Why do you use 25 decimal digits for USD amounts in your ledger?

Cheers,
Dan

[Eric Altendorf]

On Thu, Aug 10, 2023 at 1:02 AM Daniele Nicolodi <dan...@grinta.net> wrote:

On 10/08/23 06:43, Eric Altendorf wrote:
> beanquery> SELECT
>   date >   maxwidth(narration, 20),
>   account,
>   10,
>   round(cost(position), 4) as amount
> FROM >   has_account("PnL") AND
>   year(date) = 2021
> WHERE
>   account = "Income:PnL" AND  >   abs(number) < 100
> LIMIT 5

Why do you filter by account twice?

Oops, I think that's a mistake/remnant of an evolving query.

 

> I've dug around the DisplayContext updating code and can't figure out
> what's going on.  Any ideas?

The number of decimal digits used to represent amounts is determined by
the content of the ledger at parsing time, not by the data values in the
column. 

The algorithm used to determine the number of decimal digits to use
looks at the statistical distribution of the number of digits in all the
numeric values used paired with a given currency.

Oh, I see, OK.

Why do you use 25 decimal digits for USD amounts in your ledger?

I have a bunch of inputs from a bunch of sources, many contain very small transactions, and so I started off with the general principle of using the full resolution of numbers provided to me, maintaining full precision for computation with the assumption I'd round at the end for presentation.  I didn't even think about USD specifically, I just took the full numbers as provided by my financial institutions -- some of which appear to report with 25 decimal digits.

IMHO it'd be nice to be able to round off numbers or run formatting in beanquery, but (1) I understand that's not needed in the normal beancount usage pattern, and (2) it's not even a high priority for me; what I really need to solve is the transfers problem.

thanks for the explanation,

eric

 

Cheers,
Dan

--
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/818860fe-2098-4174-0a18-075c49609b53%40grinta.net.