The In & Out Strategy - Continued from Quantopian

About live trading and follow yahoo data. @Alex Rehf Nathan Swenson I was compering close prices from finance yahoo vs close prices from quantconnect there are small differences and because of that signal about in/out is not at the same time as in backtesting.

Alex Rehf I have used Yahoo Finance data and over a long period of time it becomes very innacurate on some assets/securities. Daily close prices are sometimes different and they even sometimes assume/fill in the gaps on dail close prices. I personally would not trust them as a data provider.

Someone in a Quantopian thread once said "Garbage In, Garbage Out" and this phrase has resonated  with me. We have all seen how different returns of the same algos are just from swithcing from Quantopian to QuantConnect.

Mark Reeve: Welcome to the discussion and thanks a lot for joining in! Your suggested code modifications sound amazing in terms of achieving greater backtesting efficiency and additional improvements. Regarding your points above:

• Rolling window to calculate the shifted & averaged returns: that would be fantastic to recode this. True, as you have described, the returns are calculated by dividing the current prices by a shifted (60 days) and averaged price (+/- 5 days surrounding and including the shift). Absolutely, the length of the returns sample ideally is a trading year long, i.e. avoiding that the first 65 returns are nan or missing; the issue you have described.
• Extreme returns providing the signals: I think that you describe this quite correctly, the algo uses a statistics/research logic to determine extreme return observations, which are returns that fall into the 1% left-most extreme end of the 252 sampled returns distribution (i.e. the rolling window you mention above containing the 252 returns observations, each based on the shift & average logic). Specifically, the most recent return is compared with the 252 total sampled returns (inclusive of the most recent return). An extreme observation, falling into the 1% extreme percentile of the 252 sampled returns, in any of the signals then provides the rationale to go 'out'.
• Dimmer based on the signals: a very interesting thought to determine the mix stocks vs bonds on the basis of the number of signals indicating 'out', e.g. half of the signals on 'out' = half in stocks, half in bonds. Definitely interesting to test this dimmer logic. I think in prior tests I found that being hyper-nervous (i.e. reacting to just one signals saying 'out) pays off. Specifically, I was testing whether we should wait for two signals to say 'out' and only react then. However, your dimmer idea is different from this test, so it will be very interesting to play around with that idea!

Elsid Aliaj: Thanks for sharing the gold results, much appreciated! I was thinking that your idea regarding the switch to gold as a third option might integrate nicely with Mark Reeve's idea concerning the dimmer. For instance, when things become extreme in terms of many signals (maybe 2+ is already enough) saying 'out' one might switch to non-bond assets such as gold or other precious metals. This will definitely be worth a try!

@all: also thanks for pushing hard on the live trading front, much appreciated!

Peter Guenther Mark Reeve awesome ideas, I think the 3rd option can just be the ultimate out of just cash or gold even gold we don't know how it will perform. As were only using 12 years of backtest data. Sometimes good goes through 400 year bear markets.

I think the best would be insuring the portfolio for tail events with say 1-3% of the account with OTM options.

The strategy can afford the insurance and performance "drag" to literally lower drawdowns to a measly 6%, plus you make up the drag when the black swan events strike, and you'll be out ahead. 

These events are happening more and more often it seems like almost 1-3 years now. We've had major vix blow ups multiple times, corona, multiple hard sell offs.

It's basically like free insurance since probability wise you'll hit it and breakeven on the insurance for all the years you used it.

Also regarding the extreme readings you'd probably have to test various hypothesis and have various logic in there.

Because maybe the extreme readings can happen at the start of an uptrend and would indicate a strong starting move, or happen near a top and indicate exuberance, or maybe just a continuation. 

So seems like a lot of data analysis has to occur to make a meaningful conclusion at what the 1% percentile readings actually mean.  

The only problem with this Dimmer approach, you would need the algo doing the trades as more management needed.  The current setup is nice because the trade count is so low.  It's no problem to just do the trades manually with around 10 trades per year.  Hell, someone could just post the signal in a forum post and it would be sufficient.  I don't really have a way to connect QuantConnect to my TD Ameritrade nor to my NinjaTrader.  

Hmmm, now that I think about it, can QuantConnect send emails?  I think my NinjaTrader can trade with email signal.  That would be cool because my Ninja can also trade my TD Ameritrade account.

Generally to make it works outside Quantconnect is quite challenging because of differences in source data. I was tested finance.yahoo, alpaca and polygon. And each provider has some diffrences in close prices and bacuse of that the signals for in/out are different. Prices from polygon was close to quantconnect, but they don't adjust data for dividends, only splits.

 Nathan Swenson You can write a script with any sort of selenium library to check orders everyday, and then login to your email provider and sent out an email. 

  Peter Guenther I copied your other version where it fixed an issue with holding both in/out positions. I ran it live again today, well paper trading, and it again sent buy orders for both in/out. 

So buy QQQ, EIF, TLT, GLD. 

IS this the issue since it's set to 1? Would setting it to 0 fix it? 

self.be_in = 0

something funky is going on. 

It is a bug in the code Elsid Aliaj.

Here is the correct version of algo

Hey gpw radar that is the version I am using and still send buy orders for both in/out when running live.

Elsid Aliaj: gpw radar found that we need to add tabs to the part where it says "#Thoma's reducing unnecessary trades" (and the following lines). If you put this part inside of the if clauses (via adding one tab per each line), both in the 'rebalance when in' and 'rebalance when out', then the code should work OK. The issue is that at the very beginning, in the Initialize part, we define a dictionary with all the holdings. Then it goes to the 'rebalance when out' part which runs daily and runs the 'Thomas's reducing unnecessary trades' part, resulting in the algo ordering the entire dictionary (i.e. all holdings, in and out). This should be fixed when you 'hide' that order part inside the if clauses via adding the tabs per each line. Hope this makes sense.
For future code, I will add a line in the Initialize part that sets all of the dictionary holdings to zero, just to be on the safe side ;)

Peter Guenther yeah a tad confused, so I removed a tab from the minimum order stuff is this what you meant?

No worries! It would need to look like the below. See the indent of the "Thomas's reducing unnecessary trades" part (the whole block is indented more so that it falls 'within' the if clause). You would need to make the same adjustment where the other "Thomas's reducing unnecessary trades" block is in the code (i.e. where you swap in the 'out' assets).

Hi,

i modified the logic a little bit (i used a version from quantopian, i think it was valadimir, who posted this). 

I see potentially an issue with this system.  It is based on cycles, but there are no historical sync points.  So basically if you turn it on mid cycle, you will get completely different results than if you had turned it on a week or 2 earlier.  I believe it would be better if at start it does a lookback to reach a sync point for optimum cycle entry and performance.  That way everyone is seeing similar performance, not linked to when in the cycle you start it.  

I should add, I observed this by turning it on live.  I see that it took the TLT trade today, while if you look at a run from 2008, you'll see that the TLT/IEF trade was on 10/6.  The results that follow will likely not match with other.

Nathan Swenson: Just speculating here, since I am still getting my head around how things work on the QuantConnect platform; however, could this be related to the concept of the 'warm-up period'? That is, the algo might need a command in the Initialize sequence where it is told to pre-load 252 days of historic data so that it can calculate the signals properly (esp. the returns sample on which the percentiles are based). This might be related to your observation regarding what is happening in live trading (?).

Thanks Peter!  I believe you are correct.  I have added the following warm up code.  Hopefully this is sufficient to synchronize the historical data:

Unfortunately setting warm up period is not sufficient.  Looks like you need to evaluate the bool self.IsWarmingUp and only allow logic to run once the bool is false.  This issue will affect not only live trading, but also backtesting.  You can verify this by backtesting from start date of 10, 1, 2020 for example where you'll see a QQQ trade immediately on 10/1.  Or if you start on 10/8, it immediately trades into TLT/IEF.  These trade dates do not match up to a long term test.  I am no good with Python and not quite sure the right way to implement this warm up check.  Is anyone actually doing it the right way?  I checked all the versions here and do not see warm up considered which means the startup is not quite right.  You'll end up with differing results just shifting backtest start date by a day or more.  Ideally I would expect the algo to wait for the next cycle start to enter.