Interesting discussion. Yes, the problem is always the same.
>From what I remember, Ledger creates a graph of currencies,  then, when 
required, finds the shortest path between the two. Don't remember now which 
algorithm is used for path-finding.
Also, as Martin commented in that thread, I think a runtime 
search/conversion would be a better option than creating gazillions of 
prices with a very high likelihood of not being used at all.

Correction regarding the implicit_prices. Only the pairs with direct prices 
are converted. So, remains an open issue.
On Friday, 5 September 2025 at 7:22:57 pm UTC+2 [email protected] wrote:

> On 05/09/25 19:09, 'Alen Šiljak' via Beancount wrote:
> > 
> > 
> > On Friday, 5 September 2025 at 6:50:47 pm UTC+2 [email protected] wrote:
> > 
> > This is by design.
> > 
> > 
> > Thanks for the tip. I understand the concern there and the desire to 
> > keep the core engine exact. But, the practical use cries for something 
> > that is a bit more convenient.
> > 
> > For example, I have BAM, which is pegged to EUR by constitution, and I 
> > have last week's EUR/USD rate because for me that's good enough. Based 
> > on this data, it certainly is possible to find a simple way BAM -> EUR - 
> > > USD, to express any report in any of these currencies. If there was a 
> > HUF involved, and it included rates to EUR and USD, there would be 
> > multiple way to calculate.
> > Taking the latest, or the first occurrence produces some result. If it 
> > was possible to see and understand the chain, that would help in some 
> > odd case. But once a user understand the principle and has correct 
> > records, this approach produces a very practical result - it uses last- 
> > known exchange rates to perform rate calculations.
> > This is certainly something that a middleware (a plugin?) should be able 
> > to do. I was looking already for an existing one but was unable to find 
> > anything. Hope I find something before going down the rabbit hole of 
> > writing one from scratch.
>
> Here https://github.com/beancount/beancount/issues/255 there are more 
> details. There is also a link to code in beancount that computes the 
> transitive prices
>
>
> https://github.com/beancount/beancount/blob/v2/beancount/core/prices.py#L138
>
> If someone has a good idea about how to expose that I'd be happy to add 
> it to beanquery.
>
> 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 [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/beancount/92f14a56-adce-4c77-be48-1d009d070361n%40googlegroups.com.

Reply via email to