'roi' command output change proposal

Skip to first unread message


Jan 25, 2022, 3:10:23 PM1/25/22
to hledger
Hi Simon, hi all.

This is my first post, as I started using hledger from just few weeks. I discovered it casually I must say, and I immediately realised I found the tool perfectly matching my needs to manage my personal finances.

I'd like to submit a proposal to enhance the output of the 'roi' command, namely, a command line tag to disable the IRR/TWR annualization. When applied, this tag would force the output of the rate as-it-is over a period. This way the total appreciation/depreciation of an investment can be returned by hledger for whatever time interval, like:
- an arbitrary, user-specified period.
- months (-M option), quarters (-Q), years (-Y).
Latest option makes easy to get investment evolution over time.

Another enhancement I would suggest is to enable the same -O option to change the output format. This way the user can easily export time series of an investment for post processing or plotting purposes.

Looking forward to feedbacks.


Simon Michael

Jan 25, 2022, 9:45:05 PM1/25/22
to hledger
Welcome Luca. Thanks for the ideas. I haven't used roi myself so don't have an opinion. But there is a newer, overlapping report, bal --gain, which you might want to also check out:

You received this message because you are subscribed to the Google Groups "hledger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hledger+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hledger/3a478eff-fdd0-41a7-87cb-63faa6ed2a6an%40googlegroups.com.


Jan 26, 2022, 4:08:29 AM1/26/22
to hledger
Hi Simon,

thank you for the reply. I didn't check the 'bal --gain' command before, my fault. I gave it a try, and yes it fulfils many of my requirements. Nevertheless it cannot give the full picture of how an investment performed over time as it doesn't take PnL transactions into account, and obviously doesn't return any ROI. But 'bal --gain' and 'bal pnl', along with some formatting command line options, can be used inside a script to get all the data needed to compute the investment's detailed time series and its ROI. I'll do that way.

Thank you very much.


Dmitry Astapov

Jan 26, 2022, 5:03:54 PM1/26/22
to hle...@googlegroups.com

Both IRR and TWR are annualized specifically to enable comparison / some sort of common basis for different investments.
Internally the rate is computer per day and then annualized, so on the surface it seems relatively easy to implement the proposal.

However, I think that this would open a moderately-sized can of worms.

When people say "monthly rate of X" or "quarterly rate of X", they usually mean the rate that is the same every month (or quarter, or any other period, like week).

Under this proposal, however, hledger would be reporting a rate over, essentially, "a period of N days". So for investments that grow the same amount every month, reported "monthly" rates would be different as different months have different numbers of days (and same for quarters). So it will not be a "monthly rate", but rather "a rate for the month of Jan 2022", which is a rather different beast.

So it would be surprising and highly unorthodox, but at least the behavior would be consistent: -M and -p '1 month' would produce the same results, as well as -Q and -p '3 months'. This would have to be caveated in the docs, and I bet that the resulting figures could be rather surprising (and potentially rather useless) for end users - at least on the small enough intervals (month and below).

However, if you want -M and -Q to report monthly and quarterly rates in their usual meaning, they could, of course, be special-cased in the code, but now -M and -p '1 month' will not be equivalent. Special-casing monthly and quarterly cases also opens the door to the discussion whether they should be computed allowing for compounding or not (that is, should the reported monthly rate be the rate that yields the equivalent annual rate with compounding or without).

So in my opinion it is best not to implement the change as proposed.

D. Astapov
Reply all
Reply to author
0 new messages