returns.py & --date-begin/--date-end

[Justus Pendleton]

I recently started trying out Martin's returns.py[1] and have 1 observation & 1 question.

1) It seems a bit prickly about needing price entries and doesn't really work well unless you have them in all the right places. In particular, it doesn't seem to use prices from the transactions themselves. For instance, on October 10 I exchanged from VGAVX to VEGBX {23.85 USD}. But there was no actual price entry for VEGBX. Which leads to returns.py:

    1) not knowing how to convert it to USD, so the resulting composite portfolio is e.g. 100,000 USD + 5 VEGBX.

    2) showing a -100% loss in VEGBX. Because eventually there *is* a price entry for it, so the overall portfolio goes from 100,000 USD + 5 VEGBX to simply 100,100 USD.

It is easy enough to fix by adding in the more price directives but it took a bit of debugging to figure *why* it was happening. I'm not sure if there's a better way to handle this?

Anyway, on to my real question:

The --begin-date and --end-date parameters have no effect right now, so it always calculates returns over the entire length of time available in the beancount file. I've temporarily hacked in a fix by changing the first line of compute_returns() to be:

periods = [(s.begin.date, s.end.date, s.begin.balance, s.end.balance)

               for s in timeline if s.begin.date >= date_begin and s.end.date <= date_end]

This is just a hack. The biggest problem is that the Segments don't really line up with the dates provided. For instance, if I specify 2017-01-04 as the date_begin, the first Segment is actually on 2017-01-09.

So my question is: does the segment_periods() function just need to take the begin_date & end_date into consideration, or is there a better solution?

[1]: https://bitbucket.org/blais/beancount/src/2b388a853ae4b3eb1cff288e75cdc89afcb24249/experiments/returns/?at=default

[Martin Blais]

Apologies about all the delays answering all the email, it's the EOY and I'm trying to wrap up 3 other projects (at work) before taking off for family vacation.

On Mon, Dec 17, 2018 at 11:03 PM Justus Pendleton <just...@gmail.com> wrote:

I recently started trying out Martin's returns.py[1] and have 1 observation & 1 question.

Just a quick note for context about that:

The returns.py code failed to generalize and I abandoned it at some point, with the intent to restart in a slightly different way.

I attempted to compute time-weighted returns over portfolios of assets. In the simple cases it worked fine, but I encountered a number of exceptions and issues (can't remember the specifics at the moment, it's been too long).

My intention is to restart this, but

- restart with the simpler time-weighted / IRR returns, just working from lists of cashflows

- compute those returns on individual (account, asset) pairs instead of portfolios, and 

- create some functions to combine the cashflows.

Once that works great - and it should be easier to debug - I'd graduate that to TW returns.

Note that the categorization of accounts (in three categories) I did for the returns.py code is useful though; I'd probably do the same thing when I have a second go at this.

1) It seems a bit prickly about needing price entries and doesn't really work well unless you have them in all the right places. In particular, it doesn't seem to use prices from the transactions themselves. For instance, on October 10 I exchanged from VGAVX to VEGBX {23.85 USD}. But there was no actual price entry for VEGBX. Which leads to returns.py:

    1) not knowing how to convert it to USD, so the resulting composite portfolio is e.g. 100,000 USD + 5 VEGBX.

    2) showing a -100% loss in VEGBX. Because eventually there *is* a price entry for it, so the overall portfolio goes from 100,000 USD + 5 VEGBX to simply 100,100 USD.

It is easy enough to fix by adding in the more price directives but it took a bit of debugging to figure *why* it was happening. I'm not sure if there's a better way to handle this?

No idea. I'd have to have a specific few examples, and frankly, it's been too long.

(That code was experimental, and as I said, I sort of gave up on it, with the intention to restart but simpler and more  easily debuggable.)

 

Anyway, on to my real question:

The --begin-date and --end-date parameters have no effect right now, so it always calculates returns over the entire length of time available in the beancount file. I've temporarily hacked in a fix by changing the first line of compute_returns() to be:

periods = [(s.begin.date, s.end.date, s.begin.balance, s.end.balance)

               for s in timeline if s.begin.date >= date_begin and s.end.date <= date_end]

This is just a hack. The biggest problem is that the Segments don't really line up with the dates provided. For instance, if I specify 2017-01-04 as the date_begin, the first Segment is actually on 2017-01-09.

So my question is: does the segment_periods() function just need to take the begin_date & end_date into consideration, or is there a better solution?

Ouf.. it's been too long.

I don't have the time to get my head back into that experimental code right now.

If I were you I'd restart from scratch, perhaps using the same three sets of accounts in order to extract inflows and outflows, but I'd just produce the cashflows and compute the annualized IRR instead of attempting to do the right thing and compute the TW / geometric returns. Get that solidly working, and then later on graduate that over to TW, adding what needs to be added.

[1]: https://bitbucket.org/blais/beancount/src/2b388a853ae4b3eb1cff288e75cdc89afcb24249/experiments/returns/?at=default

--
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 post to this group, send email to bean...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/36caadc8-c941-4321-ab15-17b1e1dcc05f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Justus Pendleton]

On Wednesday, December 19, 2018 at 10:19:26 AM UTC+7, Martin Blais wrote:

If I were you I'd restart from scratch, perhaps using the same three sets of accounts in order to extract inflows and outflows, but I'd just produce the cashflows and compute the annualized IRR instead of attempting to do the right thing and compute the TW / geometric returns. Get that solidly working, and then later on graduate that over to TW, adding what needs to be added.

Heh. I actually *had* restarted from scratch doing exactly that. Then I thought "Hey, let's be a good netizen and not succumb to Not Invented Here™ syndrome and just use/reuse Martin's existing work...." and threw away my fledging efforts :) I'll re-restart!