

--
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 visit https://groups.google.com/d/msgid/beancount/183f903d-f646-456a-be4a-3773633a0c14n%40googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/beancount/1d45ff0b-1ceb-434d-a1f8-00c0e45adfd9n%40googlegroups.com.
Hi Eric,
As Martin mentioned, Beangrow is code that Martin shared at some point years ago. I would consider it highly experimental, and fringe part of the larger Beancount ecosystem. I personally take that to mean “I’d be very pleasantly surprised if this worked out of the box” :). Beancount itself is mature, well maintained (I personally use v2), and has a large number of active users.
All that said, I ran your example (thanks for a simple case!), and can confirm this seems like a bug. It seems like an issue around root finding in the XIRR calculation which is done with scipy.optimize.fsolve() and an NPV formula. With your given example, the iterative process incorrectly converges towards -1 (-100%). Try running your example with the sale on Dec 31, so the time period between your purchase and sale is longer, and the formula converges to the correct IRR.
I lack the time right now to figure out why that happens numerically, but I imagine if that part of the code were replaced with an XIRR library, it would work fine. I’ve had a personal interest in getting Beangrow to work for some of my projects, but I’ve lacked the time to contribute to it. If you want to debug and contribute to that code base, that would be awesome. Your example is a great starting point. There is not much code in there, it is fairly straightforward, and there is Martin’s excellent documentation to help you understand the code well.
-Red
Hi Eric,
Applying this patch should help. It uses XIRR from this library. It certainly resolves your test case, and works on several accounts of mine (but not all). However, I’ve barely tested it, and there are cases where it might not work. Nor do I have an explanation for why the test case you presented wasn't caught earlier. Posting it here for you or anyone who is inspired to dig deeper into this issue.
--- /home/user/beangrow/beangrow/returns.py +++ returns.py @@ -17,7 +17,7 @@ from beancount.core.inventory import Inventory from beancount.core.number import ZERO from beancount.core.position import Position -from scipy.optimize import fsolve +import pyxirr from beangrow.investments import AccountData, CashFlow, Cat, compute_balance_at @@ -196,14 +196,10 @@ years = [(flow.date - end_date).days / 365 for flow in dated_flows] years = np.array(years) - # Start with something reasonably normal. - estimated_irr = 0.2 * np.sign(np.sum(cash_flows)) + date_list = [d.date for d in dated_flows] + irr = pyxirr.xirr(date_list, cash_flows) + return irr - # Solve for the root of the NPV equation. - irr, *_ = fsolve( - net_present_value, x0=estimated_irr, args=(cash_flows, years), full_output=True - ) - return irr.item()Thanks to everyone for input in this thread! Thanks Red for the code change! I'll try that later today and over a few weeks. If it doesn't work for all of my trades I'll see if I can refine it further.
Another question: Given that there are some bugs in the beangrow code and it is not actively maintained, is there any other tool in the beancount ecosystem that can calculate IRR per group of investments in a similar way to beangrow, but correctly?
Thanks to everyone for input in this thread! Thanks Red for the code change! I'll try that later today and over a few weeks. If it doesn't work for all of my trades I'll see if I can refine it further.
Another question: Given that there are some bugs in the beangrow code and it is not actively maintained, is there any other tool in the beancount ecosystem that can calculate IRR per group of investments in a similar way to beangrow, but correctly?