QuantConnect Community

Quantopian forum archive as pdf: 

Hey Kyle, good idea - thanks!

It's also archived on The WayBackMachine

Hey Guys, did anybody submit this to QC? so they can help port Vladimi's latest version, and we can pick up from there. Let me know if someone submits it or I'll do it, then we can post the QC version here, but probably maybe Vlad should do it incase the support team has questions about specific functions.

@Tentor Testivis

Kudoz!

I backtested this algo at my local PC too, the result is not as good as Quantopian too.

Chris Liu Quantopian backtest results have always been suspect, since the very beginning and i doubt they fixed anything while cutting everything down. 

As I mentioned elsewhere and even on Quantopian's forums years ago, found multiple days with wrong historical data in zipline production servers, which they said they don't go back and correct. 

I've implemented the last version I cloned from Quantopian, I belive Peter posted it.

The original code:

"""
Based on 'In & Out' strategy by Peter Guenther 10-04-2020
expanded/inspired by Tentor Testivis, Dan Whitnable (Quantopian), Vladimir, and Thomas Chang.

https://www.quantopian.com/posts/new-strategy-in-and-out
"""

# Import packages
import numpy as np
import pandas as pd
import scipy as sc

def initialize(context):
# Feed-in constants
context.INI_WAIT_DAYS = 15 # out for 3 trading weeks

# 'In' and 'out' holdings incl. weights
context.HLD_IN = {symbol('SPY'): 1.0}
context.HLD_OUT = {symbol('TLT'): .5, symbol('IEF'): .5}

# Market and list of signals based on ETFs
context.MRKT = symbol('SPY')
context.PRDC = symbol('XLI') # production (industrials)
context.METL = symbol('DBB') # input prices (metals)
context.NRES = symbol('IGE') # input prices (natural res)
context.DEBT = symbol('SHY') # cost of debt (bond yield)
context.USDX = symbol('UUP') # safe haven (USD)
context.SIGNALS = [context.PRDC, context.METL, context.NRES, context.DEBT, context.USDX]

# Pairs for comparative returns signals
context.GOLD = symbol('GLD') # gold
context.SLVA = symbol('SLV') # VS silver
context.UTIL = symbol('XLU') # utilities
context.INDU = context.PRDC # vs industrials
context.SHCU = symbol('FXF') # safe haven (CHF)
context.RICU = symbol('FXA') # risk currency (AUD)
context.FORPAIRS = [context.GOLD, context.SLVA, context.UTIL, context.SHCU, context.RICU]

# Initialize variables
## 'In'/'out' indicator
context.be_in = 1
## Day count variables
context.dcount = 0 # count of total days since start
context.outday = 0 # dcount when context.be_in=0
## Flexi wait days
context.WDadjvar = context.INI_WAIT_DAYS

# Commission
set_commission(commission.PerShare(cost=0.0075, min_trade_cost=1.00))

# Schedule functions
schedule_function(
# daily rebalance if OUT of the market
rebalance_when_out_of_the_market,
date_rules.every_day(),
time_rules.market_open(minutes = 75)
)
schedule_function(
# weekly rebalance if IN the market
rebalance_when_in_the_market,
date_rules.week_start(days_offset=4),
time_rules.market_open(minutes = 75)
)

def rebalance_when_out_of_the_market(context, data):
# Returns sample to detect extreme observations
hist = data.history(context.SIGNALS+[context.MRKT]+context.FORPAIRS, 'close', 253, '1d').iloc[:-1]
hist_shift = hist.apply(lambda x: (x.shift(65)+x.shift(64)+x.shift(63)+x.shift(62)+x.shift(61)+x.shift(60)+x.shift(59)+x.shift(58)+x.shift(57)+x.shift(56)+x.shift(55))/11)
returns_sample = (hist/hist_shift-1)
# Reverse code USDX: sort largest changes to bottom
returns_sample[context.USDX] = returns_sample[context.USDX]*(-1)
# For pairs, take returns differential, reverse coded
returns_sample['G_S'] = -(returns_sample[context.GOLD] - returns_sample[context.SLVA])
returns_sample['U_I'] = -(returns_sample[context.UTIL] - returns_sample[context.INDU])
returns_sample['C_A'] = -(returns_sample[context.SHCU] - returns_sample[context.RICU])
context.pairlist = ['G_S', 'U_I', 'C_A']

# Extreme observations; statist. significance = 1%
pctl_b = np.nanpercentile(returns_sample, 1, axis=0)
extreme_b = returns_sample.iloc[-1] < pctl_b

# Determine waitdays empirically via safe haven excess returns, 50% decay
context.WDadjvar = int(max(0.50*context.WDadjvar, context.INI_WAIT_DAYS * max(1,returns_sample[context.GOLD].iloc[-1] / returns_sample[context.SLVA].iloc[-1],returns_sample[context.UTIL].iloc[-1] / returns_sample[context.INDU].iloc[-1],returns_sample[context.SHCU].iloc[-1] / returns_sample[context.RICU].iloc[-1])))
adjwaitdays = min(60, context.WDadjvar)

# Determine whether 'in' or 'out' of the market
if (extreme_b[context.SIGNALS+context.pairlist]).any():
context.be_in = False
context.outday = context.dcount
if context.dcount >= context.outday + adjwaitdays:
context.be_in = True
context.dcount += 1

# Swap to 'out' assets if applicable
if not context.be_in:
for asset, weight in context.HLD_OUT.items():
order_target_percent(asset, weight)
for asset in context.portfolio.positions:
# Close 'In' holdings
if asset not in context.HLD_OUT:
order_target_percent(asset, 0)

# Record
record(in_market=context.be_in, num_out_signals=extreme_b[context.SIGNALS+context.pairlist].sum(), waitdays=adjwaitdays)

def rebalance_when_in_the_market(context, data):
# Swap to 'in' assets if applicable
if context.be_in:
for asset, weight in context.HLD_IN.items():
order_target_percent(asset, weight)
for asset in context.portfolio.positions:
# Close 'Out' holdings
if asset not in context.HLD_IN:
order_target_percent(asset, 0)

I don't remember the exact values for returns, DD and so on but I think the QC implementation underperforms the Q version.

I also added some plots. Btw., does any one know how to get rid of the unnecessary ones (alpha, insight...)? I disabled them in the backtest results but that doesn't seem to matter.

Hi Tentor,

Thanks for sharing the algorithm above. Since we are placing trades 140 minutes after the market open, we should ensure we set the data resolution to minute so that we avoid stale fill prices. Additionally, the algorithm makes 2 History calls every time the `daily_check` method executes. We typically suggest avoid this practice. In the backtest attached below, I've changed the data resolution to the minute-level and I've moved the first History method into Initialize to speed up the execution. Since the length of the second history call is dynamic, I've left this one to be implemented.

For those who are new to the platform, I recommend reviewing our documentation on RollingWindows, warm-up periods, and consolidators. All of these concepts are utilized in the attached algorithm.

In regards to the difference in performance from our platform and Quantopian, we can contribute this to the difference in fee models and the fact that we simulate with L1 data.

Best,
Derek Melchin

Thanks Derek!

Warmup, consolidating and all that stuff is still a little confusing to me. However, setting Resolution.Minute gave the algo from my previous post a nice boost in performance.
Now I'm off for the weekend.
You all have a great one!
 

This is Vlad's Version, I'll try to convert later if someone doesn't by then. 

# Intersection of ROC comparison using OUT_DAY approach

import numpy as np 

# ------------------------------------------------------------------------------------------------------

STOCKS = symbols('QQQ'); BONDS = symbols('TLT','IEF'); LEV = 1.00; wt = {};

SLV = symbol('SLV'); GLD = symbol('GLD'); XLI = symbol('XLI'); XLU = symbol('XLU'); SHY = symbol('SHY'); 

MKT = symbol('QQQ'); VOLA = 126; BULL = 1; COUNT = 0; OUT_DAY = 0; BASE_RET = 85;

# ------------------------------------------------------------------------------------------------------

def initialize(context):

    schedule_function(trade, date_rules.every_day(), time_rules.market_open(minutes = 140))  

    schedule_function(record_vars, date_rules.every_day(), time_rules.market_close())

def trade(context,data):

    global BULL, COUNT, OUT_DAY

    vola = data.history(MKT, 'price',  VOLA + 1, '1d').pct_change().std() * np.sqrt(252)

    WAIT_DAYS = int(vola * BASE_RET)  

    RET = int((1.0 - vola) * BASE_RET) 

    prices = data.history([SLV, GLD, XLI, XLU, SHY], 'price',  RET + 2, '1d').iloc[:-1].dropna()  

    r = prices.pct_change(RET).iloc[-1]

    exit = r[SLV] < r[GLD] and r[XLI] < r[XLU] and r[XLI] < r[SHY]

    if exit: BULL = 0; OUT_DAY = COUNT; 

    elif (COUNT >= OUT_DAY + WAIT_DAYS): BULL = 1         

    COUNT += 1         

    wt_stk = LEV if BULL else 0;     

    wt_bnd = 0 if BULL else LEV;

    for sec in STOCKS: wt[sec] = wt_stk / len(STOCKS);    

    for sec in BONDS: wt[sec] = wt_bnd / len(BONDS)         

    for sec, weight in wt.items(): 

        cond1 = sec in context.portfolio.positions and weight == 0

        cond2 = (sec not in context.portfolio.positions) and (weight > 0)

        if cond1 or cond2:

            order_target_percent(sec, weight) 

    record( wt_bnd = wt_bnd, wt_stk = wt_stk)

def record_vars(context, data):  

    record(leverage = context.account.leverage)

'''

Based on: 

Peter Guenther's OUT_DAY approach. 

Vladimir's "Price relative ratios (intersection) with wait days".

Thomas Chang changed BASE_RET parameter and reduced number of "unnecessary" trades.

Dan Whitnable added another pair and changed Price relative ratios (intersection) with intersection of ROC comparison what removed one more constant.

Many a little makes a mickle.

'''

@Tentor Testivis,
Here are my comments on Peter Guenther's "In & Out with sampled percentiles, return comparisons, and
relative ratios" algo which you just ported to QC.

Vladimir
2020-10-27

@Peter Guenther,

*In & Out with sampled percentiles, return comparisons, and relative ratios.*

Very interesting way of calculating adaptive momentum.
Very good performance metrics.
In my opinion, the range of *context.adjwaitdays* is too wide (15-80000), is this by design?
Look at Custom Data in attached backtest.

Vladimir
2020-10-28
 
@Peter Guenther,

I have manually calculated *context.adjvar* for GOLD and SILVER ratio of returns to show inconsistency of results with slight movement of SILVER price.

```
context.INI_WAIT_DAYS * max(1,returns_sample[context.GOLD].iloc[-1] / returns_sample[context.SLVA].iloc[-1]
```

returns_sample[context.GOLD].iloc[-1] =  10%

returns_sample[context.SLVA].iloc[-1] =  0.1%   --> context.INI_WAIT_DAYS*  100 --> 15*max(1,100) = 1500
returns_sample[context.SLVA].iloc[-1] =  0.0%   --> context.INI_WAIT_DAYS*  inf   - -> 15*max(1,inf) = inf
returns_sample[context.SLVA].iloc[-1] = -0.1%   --> context.INI_WAIT_DAYS* -100 --> 15*max(1,-100) = 15

@all: Fantastic to see so many familiar faces here :) I finally made the transition as well ... slow mover.

@Tentor: I big thank you for starting this thread, so that the discussion can go on! Also, incredible performance there in terms of recoding the algo and thereby quickly making it available for further scrutiny and improvement!

@Kyle: Also a big thank you to you for pushing folks early to move this discussion to QC and for providing the discussion archive from Quantopian, much appreciated!

Derek Melchin: Thank you for the warm welcome to QuantConnect and your input regarding efficient coding! If you would be happy to, and time allows, it would be amazing if you could keep and eye on this thread; your input will be highly appreciated! This thread started on Quantopian only a few weeks ago and was one of the fastest growing discussions there. We hope that this thread will also be of great interest to the QC community and that members will join in to further scrutinize and improve the in & out algos discussed here. 

@all: I will post an Intro to this thread which is intended to help new members joining the discussion to get a quick overview regarding what this thread is about (some key logics and findings from the archive). If you could help to vote this Intro up so that it gives people an entry point that would be highly appreciated. Maybe we can try to continuously keep at the top (by voting): Tentor's welcome message, the Intro, and Kyle's archive as a detailed backdrop.

(As a quick overview for new member regarding what this thread is about; please continuously vote this intro up so that it provides an entry point)

Intro to the In & Out discussion
Intuitively, it might be possible to generate excess returns via cleverly timed entries and exits in and out of the equity market. The ‘in & out’-type algos discussed here may be first steps toward developing a strategy that derives optimal moves in an out of the market on the basis of early indicators of equity market downturns. At the very least, the algos could start an interesting discussion regarding the sense and nonsense of trying to time market entry and exit in this way. Either way, your contribution is highly appreciated.

Backdrop of ‘in & out’-type algos
Looming stress in the equity market may show early in depressed prices of assets that are upstream in the value chain, e.g. resources and industrial goods. Stress may also show in increasing values of safe haven assets such as gold or USD. ‘In & out’-type algos tend to draw on these economic and sentiment indicators, e.g. via corresponding ETFs, to decide whether to be ‘in’ or ‘out’ of the equity market.

Suggested typical algo set up
1. In: The SPY is traded. This is so that the value of moving ‘in’ and ‘out’ of the market can be assessed versus the scenario of always being ‘in’.
2. Out: The money is usually invested in bonds (IEF and TLT). What we realized in our earlier discussions is that these alternative assets critically contribute to the strategy’s overall return (‘riding the jitter wave’). However, we also found that the ‘out’ indicator is not sufficiently precise, i.e. it should not be used directly to go short on the market.

Broader relevance: Amazing returns = superior stock selection strategy + superior in & out strategy
The assumption is that you will be able to plug your equity selection logic into this algo and get an additional boost in terms of your strategy’s returns. Yet, the equity selection component is not the main focus of this thread. Instead, the in & out component is which we believe tends to be underutilized in many algos.

And one to share, I reckon to celebrate the buzz that we have created with this thread on Quantopian. Here is from the members' closing remarks regarding Quantopian shutting down:
"... I saw a really amazing Algo that was posted very recently that used ETFs to find bad signals in the market so the investor could get out. It seemed to work fantastically. That algo seemed be incredibly amazing. The market good/bad signals are what mattered. What stocks you choose, as long as they were reasonable, didn't seem to matter that much. I have to wonder if they saw that and now they are off doing that and no longer needed us. Probably not but it makes you wonder." (Greg Kendall on 29 Oct 2020)

Neat idea. Have you tried playing around with equity derivatives (futures/options on SPY) to improve the precision of the "Out" indicator? Those markets tend to be pretty responsive to changes in sentiment, or perhaps some NLP on market news (there's a Tiingo News data feed here)

Peter Guenther,
Welcome back to discussion.

Someone know how to translate the following code to QuantConnect? I use these in Quantopian to reduce the lot of "unnecessary" trades.

...

    for sec in STOCKS: wt[sec] = wt_stk / len(STOCKS);    
    for sec in BONDS: wt[sec] = wt_bnd / len(BONDS)         
    for sec, weight in wt.items(): 

        cond1 = sec in context.portfolio.positions and weight == 0
        cond2 = (sec not in context.portfolio.positions) and (weight > 0)
        if cond1 or cond2:
            order_target_percent(sec, weight) 
...

 @Adam: Excellent thinking. I know that Tentor has started working on a 'futures edition' and it worked like a charm in terms of further improved total returns (at least for one of the early versions of the In & Out algo). It was particularly beneficial to integrate a clean 'copper signal' which can be an important indicator of China's production. The copper signal is included in the DBB ETF, but somewhat muddied due to the other two metals that the ETF tracks (aluminum and zinc).
Great hint there regarding derivatives and Tiingo News, these will definitely be interesting to explore!

@Validimir: will be good! Also thanks for the important points above, I reckon it will take me some time to actively look into them since I have to get my head around the coding here on QC first. Regarding the ratio examples: very true, I reckon that's the problem with using return ratios directly (small values and negative values). I will definitely give it a try regarding alternative operationalizations. I am wondering whether the actual indicator is that the alternative asset (e.g., silver) approaches a zero return while the other asset (e.g., gold) is still positive.

These will reduce a lot of "unnecessary" trades:

        for sec, weight in wt.items():
            cond1 = (self.Portfolio[sec].Quantity > 0) and (weight == 0)
            cond2 = (self.Portfolio[sec].Quantity == 0) and (weight > 0)
            if cond1 or cond2:
                self.SetHoldings(sec, weight)
 

Vladimir and Peter:
Nice to see you here and also thanks for providing some context!
I would like to quote Peter's introduction in my first post but I can't seem to edit it any more.

Thomas:
Thanks for finding the portfolio object and sharing the code - and of course nice to see you here!

Adam:
About using futures, I saw in the docs that futures data here consists of the individual contracts. Du you know how I would go about creating a continuous daily time series with them? My implementation was with the quantiacs toolbox where the futures are already continuous and Quantopian had a module called continuous_futures. Is there some equivalent here or do I need to stitch them together manually? The latter sounds a little tedious ;)
I agree with Peter about the NLP approach, very interesting! Will definitely look into it but it might take a while.
Allthough I've been a member here for some time (about a year) I was never very active and a little suprised to see that apparently I've already run over 1000 Backtests (I guess most of them were just clones). Anyway, I'll also need some time getting used to the workflow here...
 

Thomas Chang  where do you add those in?

Hi Tentor,

I would say the equity chart looks somewhat "ugly". Could you make it like this? This is much "beautiful". :-)

T

I wonder how to plot the leverage.

Has anyone else tried different time rules other than 75 minutes and observed the effects on returns? I have been looking in to this becuase a lot of my manual trading is effected by the time of day i enter trades.

I believe returns are increased slightly by changing both instances of the following line of code to 120.

time_rules.market_open(minutes = 75)
)

Thoughts on this?

Tentor Testivis 

You'd have to stitch the futures together manually unfortunately, but there's a helpful `FutureChain` class that can track futures contract on the same underlying asset. With a single asset (in this case, SPY), it shouldn't be too tedious but would be a bit of work compared to ETFs. Trading futures is limited to IB Brokerage currently as well. 

To do this, we could create an `Indicator` class, loop over `FutureChains` and update the indicator to represent the time series as the value of $1 invested in the stitched contracts. For instance,

1. Stitch together time series of rolled prices, making sure prices at the start and end match up
2. Transform into returns (rolled price delta at time t / raw price at time t-1)
3. Create a continuous non-negative time series by taking cumulative product of returns

Thomas Chang 

I think that picture is the old LEAN equity curves. You could get a local LEAN running and customize it however you want though.

For plotting leverage:

Fantastic, thanks for sharing these results, Diary of a Finance Kid! Indeed, we didn't play around with these numbers so far, so that's great. I have directly used this in my update below :)

Updated: In & Out with percentiles, return differentials, and wait day multipliers based on negative return flips of the alternative assets in asset pairs

Today, I have tried to replace the ratios with the idea described earlier, i.e. to capture when the alternative asset in the pairs (e.g. silver in the gold/silver pair) goes from having a positive return on the previous day to having a negative return on the current day, while the other asset still has a positive return (see lines 104-106). If this occurs, I am feeding in 15 (the initial wait days) as a multiplier; it doesn't matter that much what exactly the multiplier is, see my earlier comment (in the archive) that large multipliers are digested relatively quickly over time due to the exponential decay via the multiplication with 0.5 (see line 99). So this modification should take the problematic direct use of ratios out of the game. Happy to discuss the sense and nonsense of this new modification.

I have also changed the trading time to 120 mins after trading start, as per Diary of a Finance Kid's suggestion above.

Positive outcome: we are back north of the 1,000%. The backtest gives me 1,100% using the updated algo ... (hopefully no errors in the coding etc.). I still have to integrate Thomas's suggestion regarding reducing the number of trades. This is still on the list, thanks Thomas!

Gentlemen,

I too was following this thread on Quantopian. Many thanks for converting this over. Very impressive on how quiclky plus the graphs well done!. I do have question was it Vlad's version or another that greatly reduced the number of trades? Sorry i can't contribute much to the technical coding you guys are way out of my league. Nice job

Thanks

Frank

 Diary Of A Finance Kid I played around with the timing, did it near end of day ect. returns went slightly down, I think at that point where you're playing with time of day you're likely to start overfitting, but worth a shot i guess. 

Peter Guenther I tried turning off the rebalancing but kept complaing about something in the method, would be interesting to see how much of a performance boost rebalancing adds, I'm assuming not much, if so would probably make sense to turn it off for simplicity, and comission savings if running automated on say IB.

Adding QQQ instead of SPY keeps DD fairly similiar but pumps results massively. 

Also for live trading maybe some logic needs to be added to wait to start rebalancing until an actual order signal not rebalancing is given, not sure if this does it now.

@Frank: Great to have you back on board, and an important question! The reduction of trades can be achieved via Thomas Chang's code (in the archive and Thomas's new code posted above), which I reckon theoretically can be integrated into any of the 'in & out' tactics discussed here. It's still on my list to try that out for the In & Out algo. When I got it, I will post it here.

@Elsid: Great thinking, I have also played around with the 'stock selection component' via swapping in the QQQ to see what a tech stock selection would yield. I have created a spin-off thread to discuss these and other possible combinations between the latest 'in & out' tactics discussed here and superior stock selection strategies discussed elsewhere. I assume that there is a lot to discover in this space combining the two components, particularly in regard to which components work well together (synergies) and which do not (dissonance). For instance, in an old test (archive), we discovered that Vladimir's "ROC" in & out tactic combines nicely with the "Quality Companies in an Uptrend" algo originally created and posted by Chris Cain on Quantopian on 22 Nov 2019. The In & out algo did not achieve comparable results, so SEL["Qual up"] + I/O["ROC"] seems to form a better pair.
Let's see what additional strategies and combinations the community comes up with ... :)

Peter Guenther

Thanks Peter, using my limited coding skills i changed the out of market to weekly and in market schedule to monthly. I also used my favorite  ETF allocation self.HLD_IN = {self.MTUM: .4, self.XMMO: .4,self.FVAL: .2} and the results were 1.67 Sharp and reduced trades to 136 over roughly same time period.  I know we should not get into WHAT to invest but could not help myself really like this algo

Great stuff guys!  I'm new here.  Has anyone converted this over to futures with rolling contracts?  I would be interested to see the results with the high leverage and low tax consequences for futures.  I may try myself, but I'm still very green in this new environment.  My experience is in NinjaTrader.

Peter Guenther nice modifications, thank you! Just a quick question: The timeperiod for calculations of the differentials is fixed ( ~60days?)

Alex Rehf Well spotted, indeed it is about 3 months back i.e. 60 = 5 trading days/week x ~4 weeks/month x 3 months. A bit of history: when we you go back in the Quantopian archive, in the first algo version this was set to 58 days, which we then began to referred to as the 'magic 58' since slight changes in this number had a substantial impact. To be less dependent on one particular price point (i.e., exactly 58 days ago), the current algo version(s) use a shifted average; shifted by 60 days and calculated as an average using the prices in the +/- 5 day window surrounding the shift.
Other in & out algos are even less static in this regard and determine the shift period via the market volatility, see for instance Vladimir's ROC algo. I do not think that this flexible calculation works particularly well for the In & Out, but it might just be a matter of implementing it in the right way for this particular algo. So still plenty of improvement opportunities there ;)

Frank Giardina Thanks for sharing these results, much appreciated! The stock selection set looks like a nice balance between growth and value. Also, very interesting info that the results look pretty solid in the weekly/monthly trading frequency context. I have never changed the daily/weekly pattern, so that is definitely (encouraging) news for me, and the number of trades is reduced dramatically saving much money on commissions. Great!

Updated: In & Out ‒ parsimonious trades edition
The attached version integrates the code that Thomas Chang has kindly shared above; sorry for my 'wordy' implementation (see lines 121-138 and 147-163). From my understanding, the intention is that trades only occur when we switch from being 'in' to being 'out' or vice versa, but not in-between (e.g., reinvestment of dividends?). The total number of trades is reduced to 224 from 3,067 (see backtest above) over the approx. 13 year backtesting period. This is equivalent to about 1.5 trades per month in the updated In & Out version, so much more parsimonious trading here. The total return of 1,116% is pretty much the same, even slightly better.
This update might be particularly interesting for Elsid Aliaj and Frank Giardina, although Frank could reduce the number of trades even more strongly (136) via changing the scheduling function frequencies from daily/weekly to weekly/monthly (see his post above).

Hi - Peter Guenther great work and thank you for sharing. Have you tried to add Quality Comps in Uptrend with ROIC + Value factor?

Do you think adding UX1 and UX2 futures (vix futures) imporve market timing?

FYI for live trading:

1. It will enter the existing trade, so maybe some code with an Bolean True / False, if you want it to join existing orders or wait for the next signal.

2. With Interactive brokers, it sent orders, said it was filled, but nothing appeared on IB's side....this was with QC data selected, I will try selecting IB's Data feed, to see if it picks up orders. Still very weird behavior. 

S.T.E: I did not yet get a chance to implement Chris Cain's "Quality Companies in an Uptrend" algo, but I know that there are several people in the forum trying to implement it. The algo has been very popular on Quantopian, so I am sure that we will see an implementation rather sooner than later. When we get there, then one relevant finding we had is that Vladimir's ROC in & out tactic combines very nicely with the "Qual Up" stock selection, better than the In & Out, at least an old version of it.

Elsid Aliaj: Thanks a lot for sharing and, if you are happy to, keep us posted. It seems like the Live Trading implementation is again a whole different kind of beast. Good on you for tackling it!

S.T.E: just forgot: good thinking regarding VIX, as a 'fear gauge'. I gave it a try in an old version but didn't really get it to work back then. I think I tried different levels, e.g. above 15, 20, 25, 30. However, it might just be a question of implementing it right, e.g. not via static levels but via sudden jumps or similar. So, definitely an interesting indicator to play around with and see whether it could add value.

Peter Guenther thanks for your reply. Is there a reason, that you use a average of the 11 days 60 days +-5 and no average for the most recent value? In this way, you combine an averaged and non average value. I might try to modify the code tomorrow and see the results. 

Alex Rehf: absolutely, definitely worth a try I would say. My thinking was that, for the 'out' decision, we want to be fast, i.e. no 'averaged, partly historic information' including historic prices, but just the very recent information, since when things go pear shaped we may need to react quickly to new information. However, to evaluate the current price, we need a (somewhat universal) benchmark, hence the return operationalization. Yet, a benchmark resting on just one data point alone can be fickle (see the 'magic 58' discussion), so we may want to base the benchmark on multiple price points to reduce fickleness, hence the idea of using an average of multiple historic price points. So, long story short: by the end of the day, I reckon we want to assess current price drops in important economic and sentiment indicators and for this assessment we need a somewhat stable benchmark.

I'm a bit confused why you aren't using a triple leveraged SPY ETF like SXPL since it seems to complement this strategy very well as volatility slippage will be ameliorated by the predictive power of the in-out strategy. 

Also, I was wondering whether you'd tried a global ETF rotation strategy with this since many might argue that the returns might decrease in the future as we are coming off one of the longest bull runs in SPY history. While I've found that global ETFs work on their own, when combining them with this strategy (assuming that most of them would be highly correlated with the SP500), the strategy performs only moderately well with greater drawdowns. 

Also, I believe that Quantopian and QC present data differently as the quality in an uptrend model I tried had pretty different results. 

Joshua,  there is another thread where leveraged ETFs are tested in this algo::

Peter Guenther and collaberators, I am new to quantitative finance and have been folloing this thread with interest both on Quantopian and now here on QuantConnect. I was wondering if anyone has done anyone else has run backtests with cash rather than bonds as the safe haven assest and seen the performance drop massively. I was wondering how this may impact the performance of this algorithm going forward with the fed basically causing treasury bond returns to drop dramatically for the forseeable future. I guess there are other safe haven assets such as gold as alternatives but I havent tested and furthermore, I was looking at this approach for in-out signals that might be applied to a 401K plan with limited asset types, mainly to reduce drawdown. I know that the discussion wanted to stay clear of asset selection but the approach does seem to be really impacted by the performance of the out of market assets which may well behave very differently in coming months. 

As I say, I'm a new and so may be missing something here and I'd be really interested to see what folks have to say... 

Hello Matthew,

If I replace TLT and IEF with GLD and UUP (Gold and US Dollar) on the QQQ version, returned drop from 1759% to 829.6%..  The Treasurey Bonds make a huge difference in performance.  

Joshua Tsai: Welcome on board regarding this discussion! Definitely interesting points there and I would say plenty of opportunities to explore! The algo is still relatively 'young' (posted on Quantopian on 4 Oct 2020), so I would assume that the opportunities for scrutiny and improvement are still endless. As Nathan Swenson noted, we have just begun to discuss the stock selection strategy (and leverage) in this thread here. We have not yet tried an ETF rotation strategy of the kind you have described, just a very simple tech selection strategy, so your findings are definitely very interesting. What would also be interesting is to try and run your ETF rotation strategy with another in & out-type strategy, such as Vladimir's ROC.

Matthew Wormington: Also to you, welcome to the team! Absolutely, great tests regarding cash vs holding the bonds and great thinking. Consistent with your tests, we also found that the contribution of bonds is substantial; for some of the findings, see in the Quantopian archive using the search terms: "Just musing, but it almost seems the signals are really just finding when to get into bonds?", "Earlier theme: Contribution of bonds", "Conclusion: 'out' = signal for return opportunities in alternative assets and possibly investors' crystal ball for market downturns, although these may not actually materialize". 
In terms of holding alternative assets other than bonds, I think that, on Quantopian, Frank Sch was reporting an improvement by adding 10% gold to the basket plus 45% of each of the bonds. However, he was using a prior version of the In & Out together with a certain stock selection strategy ("Quality Companies in an Uptrend"). Regarding your question concerning whether we can assume that bond returns will equally contribute in the future, here is my take, others may see it differently:
<< ... I reckon for backtests that is the question: are we sufficiently confident that the future will look like the past? There can only be opinions about this since no one can predict the future, so here is my opinion: the past decade was characterized by cheap debt capital, which fuelled company growth and margin-based trading (trading with borrowed money). Due to the Covid crisis my assumption would be that the next, at least, half a decade will look very similar. So, it could be valid to say that the (near) future is likely to look like the past. Now, the bonds basket generated excess returns in the past despite it being the environment that is was (e.g., low interest). So, I would assume that this basket can also generate excess returns in the (near) future. >>

 Nathan Swenson OK, glad that it's not just me. Given the impact of the fed for the forseeable forseeable future on Treasury Bonds and them having such low returns then it will be interesting to see how this algorithm paper trades in coming months. It might be critical to consider alternative risk-off assests than in the past so as not to be very mislet by backtests. For example, using GLD and UUP you take a 2x hit but its nothing like the hit you take going to cash or possible treasuries for months/years. So alternate risk-off assets might be critical to have this algorithm perform going forward. At least from the perspective of a newbie... 

As this strategy doesnt need to be traded automated, i set up a telegram bot notifying me, when the status is changing. 

has anyone played around with alternatives for IEF and TLT?

Alex, this is exactly what I want to do.  I plan to trade the signals with my NinjaTrader futures platform and my TD Ameritrade account.  Regarding playing around, please check the other thread where I ran it with SPXL and TMF to reach nearly 40,000% return from 2008 to 2020.

Can you show me the code you used for the SMS?

Nathan Swenson I used the code (more or less as it is) and used yahoo finance to get the stock data. i just started the server in my amazon cloud. 

Interesting.  I didn't realize you could run this code outside QuantConnect.  I was going to just pay the $28 for the live trading node and paper trade it.  Was hoping for some alert system to notify me of pending trades.  

Read an article awhile back too, performance for bonds still perform fairly well even during rising interest rates, especially the 7-10 year duration, they don't get hit nearly as hard as others. The only time it gets hit hard is rates sky rocket to like say 20% or something. 10% GLD should be more then enough to cover as insurance for bond losses. 

I think GLD should have it's own logic, a 2nd out so to speak, if not in stocks & not in bonds then x% in GLD. would be interesting to test. 

Here is backtest with GLD added in as a 3rd option, split between bonds 33/33/33. returns drop slightly DD goes up by .50%. Problem is even with gold we're assuming a continous uptrend or some sort of correlation with bonds for the out signal. Think like i mentioned above gold should be split into it's own signal, so it's weighted against the performance of stocks and bonds.

Because the whole hypothesis is what happens if bonds don't perform, if bonds don't perform it will throw the signal to IN and you wouldn't be holding GLD anyway.

Alex Rehf You'd still need to run it with live data to get the signals at 11:30. Or are you waiting and trading it next day, as yahoo data doesn't provide live realtime data I don't believe. 

Actually what's needed is not us playing around with the GLD's of the world, trying to predict will bonds perform in the future or not. What we need is a tail risk system like Taleb's at Universa. Then you can switch this strategy to say something like long only with 3X ETFs while having the out of money options to protect downside. 

But from what I've read about options protecting your downside usually ends up costing too much, so I wonder if anybody knows or has experience on how Universa implemented it to generate 4000% returns in March. They were able to hedge a hypothetical S&P Portfolio with only around 3% of invested in the tail fund which covered about 12% drawdowns. 

You could theoretically run say a 40% DD algorithm assuming it's producing outsized returns of say 40-50%, buy about 10-12% of tail risk protection, and capture around 30-40% almost risk free, assuming a sound trading strategy that produces gains.

Elsid Aliaj Yes, thats right. My plans are use an other data provider to get the current price of that day.

Hi All,

I am looking at this algorithm and trying to wrap my head around a few methods used within. 

For starters, doing the history request DAILY is super inefficent and massively slowing down your backtests. You are trying to compare price to where it was 58-days ago... or in more recent versions the MEAN of 55-65 days ago... 

If this was all you were doing then simply using the MomentumPercent indicator would do the trick with no need for repeated history requests (See Basic Indicator Usage), and no need for any hist.shift()

However, it seems like you are ALSO using the history request to calculate the historical significance of the most recent return_sample: 

In this instance you are probably best served by creating a Rolling Window of the close prices, 65days long, and then using this for all your calculations above.

We recommend using RollingWindows to hold periods of data instead of making multiple Historical Data Requests. It is much more efficient as we just need to update the RollingWindow with the latest data point, while a History call fetches the whole requested period and synchronizes the data.

I'll try and code all of the above and post here when done...

Meanwhile, picking the MEAN of 55-65day lookbacks avoids the need to specify exactly which day, it does still however comes down to ONE single day. Why not chose them all? Create an ensemble, 11 different signals, and  trade them all, effectively creating a dimmer switch for the IN_OUT functionality of this algo - instead of the wham bam 100% IN today, 100% OUT tomorrow signal?

I also meant to point out - it appears you are requesting 252 trading days of history. Using 65 to measure returns, but this then drops 65days of data for your "extreme observations".

You arent doing them on 65-days and you arent doing them on 252-days, you are doing your calculations on 252-65 = 187-days. As in returns_sample is 187-days long. Was this your intention?

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.  

I think I have a solution to this problem if I understand it correctly. Nathan Swenson Peter Guenther Please check out this code. So generally we will open the position only when the fresh signal is generated. I achieved it this way: long story short algo will open position after the second signal is generated. So we skip the first signal to avoid the situation open position in the middle or at the end of the cycle.

gpw radar: Thanks for the code! That looks good in terms of preventing 'between cycle' entry at the beginning when starting the algo. When live trading, I (= personal preference) probably would want to hold what the algo is holding right away, but I see the point that there might be an advantage of waiting for the next cycle; however only if we assume that the positive returns are sitting at the beginning of each cycle vs mid way or at the end.
Only one observation: I am not sure whether the gold holding is properly reset when being 'in' the market. I think it is defined at 0.33 in the Initialize dictionary and then in the final if statement (if self.be_in:) wt[self.GLD] is not set to zero, which I think should lead to a leveraged holding of being 100% in QQQ and 33% in gold i.e. at 133% investment. I could be wrong, so probably best to check the orders.

Peter Guenther Yes, I got your point. I just implemented a solution (probably) for the problem described by Nathan Swenson 

 Ah sorry for that I just copied someone's code and added logic about not enter into the market at the beginning as we don't know where we are in the terms of the cycle. And yes you are right about holding gold it is a bug in the code.

Peter, I also agree that it's a preference choice.  My thinking was I would manually sync by checking the last historical entry and see if the asset price was the same or lower as the algo entry.  If it is then enter.  My concern was mostly about the wait period and getting off ideal cycle timing.

Thank you for looking into this Gpw Radar!  I will review your edits.  I really need to get up to speed on Python so I can help you guys more.

Update (2nd): In & Out ‒ parsimonious trades edition
Just a quick update of the In & Out algo trading the QQQ (feel free to change the stock holding), addressing some issues:
(1) warm-period: Included a warm-up period, pulling historical data to calculate the relevant indicators (see lines 62-3; also see Nathan Swenson's earlier comments). I set this to 350 days which actually is more than we need. Better safe than sorry.
(2) being neither in nor out at algo start: The default of the previous algo versions was that we are 'in' when starting the algo. I have changed this by setting self.be_in to an arbitrary number (999), which is neither 1 (in) nor 0 (out) (see line 55).
(3) simplified setting of holdings: The earlier operationalization of the holdings weights (self.wt) was suboptimal since we defined weights in the Initialize part and then manually overwrote them in the two rebalancing parts, which can lead to unwanted errors (e.g. via overwriting using the wrong weights or forgetting to overwrite one of the holding parameters). So, I reformulated the codes (see lines 124 and 140). As a brief explanation: What we are basically doing here is we concatenate two dictionaries (matching stock tickers and corresponding weights): the 'out' holdings dictionary self.HLD_OUT = {self.BND1: .5, self.BND2: .5} and the 'in' holdings dictionary self.HLD_IN = {self.STKS: 1}. Python does a dictionary concatenation via the code {**dictA, **dictB}. However, depending on whether self.be_in says 'out' (lines 123ff) or 'in' (lines 139ff), we set all of the weights in one of the dictionaries to zero. For example, in the case that we want to be 'in', all of the self.HLD_OUT weights are set to zero via the code dict.fromkeys(self.HLD_OUT, 0) (see line 140).

Any coding errors, give me a shout or post an update.

Thanks Peter, I just re-added the GLD.

New to QuantConnect -- quick question -- I was thinking to put my money where my mouth is. Do you think an L-MICRO server could handle this algo? (maybe I should save that question for support but I was thinking to throw some money at the in/out and see how it works with real money)

Peter, it looks better.  Now if I set start date as 10/1/2020, I see the trade into bonds on 10/6/2020, but there is still the QQQ entry trade on 10/2/2020 that doesn't align with the longer term backtest.  In this case it's a good trade.  Perhaps it's fine as it is in sync as of 10/6.

Peter, looks like it"s using too much memory with the long warm up period if running live:

Ok, I don't believe the warm up is benefiting the algo.  When I comment it out, the trades are the same.  I'll just leave it out for now.  Perhaps the other edit you made is sufficient?

@Nathan Swenson: Good to know regarding live trading and data requirements. You could try and shorten the warm-up period. In addition, maybe someone from QuantConnect could advice regarding what's going on in terms of warm up in live trading.

Regarding the entry into the QQQ trade: The algo update does not include gwp rader's modification regarding waiting for the next cycle to enter. Technically, the algo is 'in' the market from 11 Sep 2020 to 6 Oct 2020, so when starting the algo on 2 Oct, we would directly go 'in' (since the algo is 'in' at that point in time, basically since 11 Sep). Then comes the swap to bonds on 6 Oct.

If you prefer to wait for the next cycle, gwp radar's code additions are relevant:

Guys, I have one concern as I got a different result when I run something like this (comparing to your code): 

        self.Schedule.On(
            self.DateRules.EveryDay(),
            self.TimeRules.AfterMarketOpen('SPY', 1),
            self.calculateSignal
        )
        self.Schedule.On(
            self.DateRules.EveryDay(),
            self.TimeRules.AfterMarketOpen('SPY', 120),
            self.rebalance_when_out_of_the_market
        )
        self.Schedule.On(
            self.DateRules.WeekEnd(),
            self.TimeRules.AfterMarketOpen('SPY', 121),
            self.rebalance_when_in_the_market
        )

In self.calculateSignal I just run the all calculation to get in/out paramter. Others two function are just to open/close trades.
Why am I get a different result? Here is my deduction (I can be wrong):
When your code sets two functions to fire 120 after the market open I believe the program runs it at the same time. So the function rebalance_when_out_of_the_market does not finish its calculation but the second function was fired and use the wrong in/out parameter. I will try modifiy Peter Guenther and will upload the result we can compare it.

gpw radar: Cool test, will be interesting! I would set the signal scheduling function to 119 mins after market open, since having it at 1 min can have an impact. I often find that the market behaves relatively 'erratic' in the first few minutes (up and down a lot), while, when we are 1-2 hours into the session, the picture often becomes a bit clearer in terms of where the journey is going to.

Peter Guenther Sure, but when you calculate the param in/out your algo every time use historical data am I right? So it does not matter when you start the calculation. I ran quick test and run calculation after 1min start and after 120min start and in both log the content of the history param. It was the same. And as far as I understand the code you only use the historical data. Anyway `set the signal scheduling function to 119 mins` is also fine in my opinion as you will calculate the signal and the function rebalance_when_in_the_market will be fire 1 minute later.

OK the test finished. It is a tiny improvment 1,733.59 % vs 1714.767%.
Interesting that drawdown also improved 13.5% vs 16.5%

Mateusz Pulka: Great tests, thanks for sharing! That's good to know that the algo performance is robust against enforcing a strict chronology regarding the 'out' trades and 'in' trades. Good stuff!

Goldie Yalamanchi: Thanks for joining the discussion! I reckon that the algo does not need huge capacities to run properly, due to the limited number of stocks/ETFs that are traded or used in the calculation and the small number of calculations compared with more complex stock selection strategies. Also, trading occurs only every 1.5 month, on average.

@all: for live trading, we are still searching for code that would wait for the confirmation that the sell orders are filled before submitting the buy orders (also see the discussion here: https://www.quantconnect.com/forum/discussion/9632/amazing-returns-superior-stock-selection-strategy-superior-in-amp-out-strategy/p1). This is to ensure that sufficient funds are available for the buy orders. If anyone has a suitable code snippet, that would be amazing :)

Hi Guys, First of all, amazing work on this project! I've been following along and thinking about different ways the algo could be improved. I got particularly interested in the tail hedge portion. From what I've looked at, it seems like using an option on the VIX index above a certain level, (let's say 25) could prove beneficial, however, I am not much of a coder so I am not really able to create the code for that. Is there anyone working on the tail hedge? I would love to help with the theory/data analysis.

Peter Guenther I added the bit of code below to sort by weight low to high which should make sells happen first. Checked the output and looks like it.

self.wt = {k: v for k, v in sorted(self.wt.items(), key=lambda x: x[1])}

One more thing, I want to make this work for like a Roth IRA with no taxes, so I can contribute x more dollars every year and that should trigger a re-allocation somehow. Maybe it is not required by other people but I think I am going to work on that next.

@Lukáš Ceplický I think I can try to implement your idea to improve the strategy. How I can reach you to talk about the details?

100th comment
@all: Just to celebrate, this thread has 100 comments :) Great questions, ideas, and contributions from all, keep up the great work! Congrats to all on this milestone!

VIX fear gauge indicator
Luk&aacute;&scaron; Ceplick&yacute; Intruiging idea there regarding using the VIX as a fear gauge. I have tried in the past but was not particularly successful with it (e.g., using certain levels such as 15, 20, 25, 30, 35 as cut offs). But I believe that it could just be a question of implementing it right.

Execute selling orders before buy orders are submitted
Goldie Yalamanchi: Nice sorting code to ensure that the selling orders are submitted before the buy orders. I am currently looking into whether there is a way to wait for a full confirmation that all the selling orders are filled before the buy orders are even submitted; as a precaution that funds are available in the event that the selling orders take some time to be filled. Possibly the QC team has a code snippet for us that might achieve this? (Shile Wen, Derek Melchin)