Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overlapping drawdowns #145

Closed
jlopezpena opened this issue Sep 22, 2015 · 2 comments
Closed

Overlapping drawdowns #145

jlopezpena opened this issue Sep 22, 2015 · 2 comments
Labels

Comments

@jlopezpena
Copy link
Contributor

The get_top_drawdowns function in timeseries.py sometimes returns overlapping drawdown periods, which should not happen. This code reproduces the issue:

import pyfolio as pf
stock_rets = pf.utils.get_symbol_rets('FB')
pf.timeseries.gen_drawdown_table(stock_rets)

which produces the following output:

screen shot 2015-09-22 at 14 24 48

Drawdown with index 6 starts on 2014-10-24, finishes on 2015-01-15
Drawdown with index 5 starts on 2014-10-28, which cannot be a peak as then it would have meant the end of the previous drawdown.

Problem occurs on timeseries.py lines 770-772:

            underwater = pd.concat(
                [underwater.loc[:peak].iloc[:-1],
                 underwater.loc[recovery:].iloc[1:]])

the actual peak is getting removed from the series, allowing a subsequent drawdown to engulf the one that just got cropped. The cropping should start on the index immediately after peak. Assuming that indexes are always day-based replacing line 771 by

[underwater.loc[:peak + pd.to_timedelta("1d")].iloc[:-1]

seems to fix the bug.

@jlopezpena
Copy link
Contributor Author

Partially related to this, lines 770-772 seem like a rather inefficient way of removing data from the series, an overall more efficient way would be to directly drop the unneeded lines rather than chop and concat:

underwater.drop(underwater[peak: recovery].index[1:-1], inplace=True)

I can write a PR if this is a bug and not the intended behaviour.

@twiecki twiecki added the bug label Sep 24, 2015
@twiecki
Copy link
Contributor

twiecki commented Sep 24, 2015

@jlopezpena Many thanks for reporting. A PR with a fix and your suggested improvement would be greatly appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants