beanprice displays prices with precision higher, than available from the data source

[Ev2geny]

Issue

Under certain conditions beanprice displays prices with precision higher, than available from the data source. The extra precision is created by adding extra zeros, which does not provide any added value.

expected behavior

beanprice would never display prices with the precision higher, than received from a data source

How to reproduce

So far so good

ledger.beancount

2025-05-20 commodity AAPL
  price: "USD:yahoo/AAPL"

bean-price ledger.beancount -i --update

Here the prices are displayed with the maximum available from the data source precision:

2025-05-20 price AAPL                   206.86000061035156 USD
2025-05-21 price AAPL                   202.08999633789062 USD
2025-05-22 price AAPL                   201.36000061035156 USD
2025-05-23 price AAPL                   195.27000427246094 USD
2025-05-23 price AAPL                   195.27000427246094 USD
2025-05-27 price AAPL                    200.2100067138672 USD
2025-05-28 price AAPL                    200.4199981689453 USD
2025-05-29 price AAPL                    199.9499969482422 USD
2025-05-30 price AAPL                   200.85000610351562 USD
2025-06-02 price AAPL                    201.6999969482422 USD
2025-06-03 price AAPL                   203.27000427246094 USD

Let us now add some price entry in the file, which will help beanprice to derive expected precision (in our case no numbers after comma)

ledger.beancount

2025-05-20 commodity AAPL
  price: "USD:yahoo/AAPL"

2025-05-28 price AAPL                    200 USD

In this case beanprice displays prices with inferred precision even though a better precision is available. This makes sense

bean-price ledger.beancount -i --update

2025-05-29 price AAPL                                  200 USD
2025-05-30 price AAPL                                  201 USD
2025-06-02 price AAPL                                  202 USD
2025-06-03 price AAPL                                  203 USD

!!! Now the problem !!

If we try to artificially pump the expected precision

ledger.beancount

2025-05-20 commodity AAPL
  price: "USD:yahoo/AAPL"

2025-05-28 price AAPL                    200.00000000000000000000000000000000000000000000000000000000000000000000000 USD

Then beanprices tries to match it, even though this precision is not available from the data source

bean-price ledger.beancount -i --update

2025-05-29 price AAPL                   199.94999694824220000000000000000000000000000000000000000000000000000000000 USD
2025-05-30 price AAPL                   200.85000610351562000000000000000000000000000000000000000000000000000000000 USD
2025-06-02 price AAPL                   201.69999694824220000000000000000000000000000000000000000000000000000000000 USD
2025-06-03 price AAPL                   203.27000427246094000000000000000000000000000000000000000000000000000000000 USD

Notes

There is another similar issue available #92
It may or may not be the same, as the latter does not have much information on how to reproduce

[alensiljak]

Thanks for elaborating! I had the same issue. However, I searched for decimal places

select * where round(number, 6) != number

and there was no records with that many decimal places. I looked for both number and cost_number.
I was debugging the print function but did not really figure out why all the prices were maxed-out with zeros. The currency precision was different for different currencies, while prices were all with almost the same number of decimal places.
After I fixed the price source to return the decimals as reported on the exchange (the source I was testing with was returning some crazy amounts with multiple decimals, but max. 6, not 18), the places were padded with 0's.
After reading your description, I assume the decimal places were jacked-up by implicit prices, since I'm using

plugin "beancount.plugins.implicit_prices"

in my book. But that is still just an assumption.

Based on the recent check-ins, Martin is working on the precision setting so that might eventually resolve the problem.

As a workaround, I wrote a simple script that strips the right-most zeros from the prices in the generated price file. This will work for now, as I'm focusing on completing the importers and other price sources.

[alensiljak]

I have an assumption why this is happening in my case. There are no prices with that many decimal places in my book. However, I noticed that, if there is something like
15.6342793 units @ 1.958346 AUD
the inferred precision will contain as many decimal places as both of these numbers together. I noticed this in seemingly innocent deposits to a mutual fund, of $100 at a time.
This, however, is intentional and is explained somewhat in one of the docs.
And, as mentioned, Martin is working on the feature where an implicit precision for display will be configurable. That will likely solve this problem. The precision will still probably be as high but will not display as such. That's my guess, at least.

[Ev2geny]

I think whatever the mechanism of determining inferred precision is, the beanprice still shall not display prices with the precision higher, than the precision received from a data source by padding extra zeros at the end. Hence this issue.

[Ev2geny]

I think I found an easy workaround

If before this line you add

dcontext = None

then beanprice does not try to be clever and just displays prices with the precision, which was received from the source.

May be the solution can be as easy as adding an option to beanprice to not be clever.

something like

-r, --raw          Print prices with the raw precision, received from the data source. Ignore precision, inferred from the ledger.