def-mycroft / pairs Goto Github PK

wouldn't be too bad to use heroku or even a little aws server to spin up a web app.

I'd use Heroku and plotly dash for sure, I've built a handful of little webapps like that. heroku offers a free version too.

with plotly could easily create a formatted table of the trade history and get into some graphs.

would be cool to have this on heroku to make the project accessible to non-technical people.

also would be able to run this on localhost and create a browser-based application.

statsmodels.tsa.stattools.coint (here is the documentation) can be used to calculate cointegration. this should probably be a row in the output table.

it would be useful to see what the latest share sizes for the pair are in the backtesting output. these sizes change based on realized volatility, so only the latest one would be used. it might be best to isolate the size calculation logic into its own module in the process of doing this as well.

currently, only data gotten from yfinance can be used. will want to allow for arbitrary data input according to some format.

Module pairs/lib/backtest/backtest.py contains the backtesting logic. A description of what this logic is should be written.

given the same input data, the results should be the same every time the backtest is ran, however this isn't the case:

(base) [main] m $  pairs analyze-pair
running backtest for FB-AMZN using archived data:
done, here are stats for FB-AMZN:
|    | metric               | value                     |
|---:|:---------------------|:--------------------------|
|  0 | date_min             | 2019-03-14T00:00:00-05:00 |
|  1 | date_max             | 2021-03-12T00:00:00-06:00 |
|  2 | count_data_points    | 504                       |
|  3 | count_trades         | 21                        |
|  4 | winrate              | 52.38%                    |
|  5 | count_losing_trades  | 10                        |
|  6 | count_winning_trades | 11                        |
|  7 | profit_max           | $10.36                    |
|  8 | loss_max             | $-47.72                   |
|  9 | sum_profit           | $-174.41                  |
| 10 | profit_mean          | $5.56                     |
| 11 | loss_mean            | $-23.56                   |
(base) [main] m $  pairs analyze-pair
running backtest for FB-AMZN using archived data:
done, here are stats for FB-AMZN:
|    | metric               | value                     |
|---:|:---------------------|:--------------------------|
|  0 | date_min             | 2019-03-14T00:00:00-05:00 |
|  1 | date_max             | 2021-03-12T00:00:00-06:00 |
|  2 | count_data_points    | 504                       |
|  3 | count_trades         | 21                        |
|  4 | winrate              | 57.14%                    |
|  5 | count_losing_trades  | 9                         |
|  6 | count_winning_trades | 12                        |
|  7 | profit_max           | $10.36                    |
|  8 | loss_max             | $-47.72                   |
|  9 | sum_profit           | $-168.23                  |
| 10 | profit_mean          | $5.93                     |
| 11 | loss_mean            | $-26.60                   |
(base) [main] m $  

I've not yet ran this on Windows. It should more or less run on Windows out of the box, although there may be some minor changes required to make it work.

It might be nice to optimize the params, i.e. try a large number of different lookback windows and standard deviations to find ones that empirically were "best" according to some objective.

one hard part about this is that it may be too intensive for the current code...may consider integrating somehow with Stratagems.jl anyway, which would make optimization more possible.

I think this is a pre-req for a handful of other issues that are currently open, e.g. #9 (Tiingo addition), need to be able to accept api key from user and store it somewhere.

cement as config support.

should be able to run pairs config and walk the user through a configuration setup and ask for things like API keys and desired data storage location.

need to be able to verify that the code is behaving as expected, and a good way of doing this is to feed a frozen dataset into the backtesting logic and compare the generated results to a frozen copy of the generated results.

as of now, there is a python module fb_amzn that contains a csv file (as a string) that is two years of $amzn and $fb data. this could be used as the input for the test.

the parameter values that are being used in each backtest should be visible to the user in the display table.

figuring out how to size the spread is a little bit tricky and having a calculator tool would be helpful.

there is already functionality that can model the spread (see here), that can be used to get a standard deviation of the spread price.

users could put their capital base and other similar params in the config file (a new section) and the cli would then spit out the number of shares and spread price thresholds.

also would want to calculate a maximum size for each leg, based on a 2-sigma daily move and risk parameter, it is important to avoid oversizing individual legs on these trades.

currently the backtest params are in pairs/lib/params.py. should be able to pass these from the command line when running a test.

create functionality that scans a very large number of potential pairs, backtests a subset of them and returns pairs that have good backtesting scores.

there are a whole host of different potential problems with this and this is likely to be a really good way of showing that there is a huge difference between backtesting and actual trading, but regardless I think it could be useful.

finding a way to reduce the number of backtests might be key to making this possible. one way would be to create a correlation matrix of all candidate assets and only run backtesting on ones that meet a certain correlation level.

would need to evaluate whether or not all of this could be done in-memory or not, as well.

https://www.tiingo.com/

there is a free option as well as a relatively inexpensive paid option.