Glen’s Journal

[JulianCohen]

Thanks Glen.

It didn’t occur to me that Norgate might be to blame They so rarely make errors so I naturally assumed it was me.

Thanks for pursuing this..

[TimothyStrickland]

Glen, my MR system has been taking a haircut as well, think its just the timing at the moment.

[GlenPeake]

Tim Strickland wrote:

Glen, my MR system has been taking a haircut as well, think its just the timing at the moment.

100% agree. Since a number of us here who trade MR systems are experiencing similar performances atm…I also put it down to MR systems being ‘out of sync with the market’ atm.

[ChrisThong]

Hi Glen,

As you are trading more than one MR strategies, can I ask how do you deal with the situation where you would be buying the same symbol for two different strategies? I ask this is because, I am currently developing a second MR strategy to trade the S&P500 and from 1/1/2005 to 30/7/2021, I have 1610 (or 16%) instances where the potential S&P500 and currently trading R1000 strategies traded the same symbol.

[GlenPeake]

Hi Chris,

Yes… I’m currently trading 5 MR strategies.

Yes, I do get the same symbol(s) flagged as a setup across strategies from time to time. In those situations, I always place the orders for all signals, even when there are ‘double ups’ across strategies. (There are different stretch values between systems therefore different BuyLimit entry levels etc…some might get filled, while others may not get filled).

There are just times when a stock will get flagged by a/any MR strategy(s) due to the nature of the price action, e.g. high VOLA etc. e.g. $GME was flagged on a couple of my strategies recently and I got filled yesterday @ $180 and sold on OPEN tonight for $198.41… so there will be times when it works for you and times when it goes against you.

You can limit the double ups from happening (to a certain extent)….by:
– Having unique/differing Ranking between strategies…. e.g. 1 system might use ROC, while the other system might be ATR
– Differing Stretch values…
– Differing strategy approaches, e.g. looking for “heavily” oversold setups OR buy the dip in an uptrending stock (i.e. short pullbacks) etc
– Different universe of stocks…. my MR#4 & MR#5 systems target the entire universe of US stocks…. (price filters are turned on).
– If you’re trading an MR system on the S&P500 & R1000, you could tell your R1000 system to ignore stocks if they are in the S&P500….that way no double ups….(maybe this would reduce the quality of some of the setups and hurt returns etc….testing required here)
– Perhaps, down the track, if/when you’re interested, you can take a look at RealTest backtesting software (https://mhptrading.com/), which will allow you to configure multiple strategies into the one script file and you can tell RealTest if System#1 has generated a signal/order for stock XYZ, then System#2 cannot take the same signal/order for stock XYZ on the same day etc.

[TerryDunne]

My personal view is that there is too much focus on the risk of these trades and not enough on the reward. When more systems choose a stock, that’s the same as more votes for doing the trade.

In a mathematical sense, assuming systems with 60% win ratios, being chosen twice lowers the likelihood of it being a loser from 40% to 16%(?)

[JulianCohen]

If you carry that thought further Terry, it means that if you choose four or five times, the chance of being wrong is tiny….However the fact remains that when you are wrong in this case, the risk is very large. And the one thing we know from history is that as far as large adverse movements go, the stock market does not follow the mathematic rules of risk and standard deviation….

That’s one reason I don’t like having strategies that choose the same stock more than once. I like to play defence and let offence take care of itself

[TerryDunne]

Yes, I think I’m mis-applying the maths.

Nonetheless, I think the point is still valid. I’ve found that two things are the main drivers of MOC/MR system performance, stretch and rank. Bypassing trades in one system because they are in another system undoubtedly means lowering the quality of the rank…

Personally, I do sometimes have up to 4 trades in the same stock. If I don’t then I’m not following my systems.

In terms of the risk, let’s assume that you have two systems taking up to 20 positions each. If the same stock appears in both, then there is an allocation of 5% to that stock. If you only trade one system taking up to 20 positions, there is a 5% allocation to that stock.

Of course, ‘allocation’ is not the same as risk. Let’s say your doubled up stock goes horribly wrong and loses 20% – that’s a 2% loss. So…to lose 2% you need both a doubled up position and a 20% loss. I’m not saying this won’t eventually happen, but surely it’s more likely that the stocks that qualify in two systems make money.

I’ve never considered myself an optimist

[JulianCohen]

You’re right…there is a big difference between allocation and risk so your point is well taken.

I have been using RealTest for my MOC and MR strategies as it is so easy to develop and test on a portfolio level. I found a combination of strategies that backtests well when the same stock is not taken more than once, so I have been able to backtest the principle behind this thinking, at least with my particular strategies.

A agree, stretch and ranking are the main considerations when combining strategies and I have tried to develop systems that access different universes in order to find less repeated stocks. Where I have two strategies with the same universe, I use a different entry algorithm and a different ranking method in order to try to find different stocks.

[JulianCohen]

Sorry to hi-jack your thread Glen but I tested Terry’s theory yesterday and in my case he is right. For the strategies I have in place in the universes they are working in, allowing duplicate entries across strategies added 8-10% to the CAGR and only -1% to the MDD.

So Terry you are right….the risk involved is minimal compared to the returns. Testing is everything! Thanks for making me think about it.

[GlenPeake]

Update on the ASX Small Ordinaries Monthly Rotational build.

Testing continues….. The system looks solid and robust.

I’ve got a few variations of the system…. below is a few sample/snapshot backtests from various time periods.

Planning on using the remainder of SEPT to run some more tests and then start live trading it in OCT….

[JulianCohen]

Looks good Glen

[GlenPeake]

Thx Julian. The system should offer nice diversification between my ASX100 RTN & WTT systems on the ASX.

[TrentRothall]

Hi Guys

Glen sparked my interest in testing a small ords/ asx300 rotation system.

I ran a fair few tests and different combinations of position sizing, number of positions etc. The results for EOM systems using both 10 positions or 5 positions weren’t too bad so far. Not as good as glen is getting but a good start.

I decided to try running the system similar to how Nick and a lot of the other here are doing. In two batches roughly a fortnight apart. I believe this is correct? One at the EOM and one mid month.

The results weren’t good. Mainly due to the luck and timing with Covid. As Nick has spoken about before. I’m not sure if you’ve tested this Glen or checked out for robustness but might be worth taking a look.

I used the following code to do this in RT ( i think it’s correct)

Code:

System1: (Week % 4 = 0) and EndOfWeek // Friday every 4 weeks
System2: (Week % 2 = 0) and EndOfWeek and not System1 // Friday every 4 week but fortnight different to above

The below is the same system, one just enters/exits at the EOM the other starts in the 4th week of the year then every 4 weeks after. Interesting the difference

[GlenPeake]

Your EOM system stats look good. Very nice indeed. Similar to mine, which kind of validates the numbers I’m seeing. I.e. knowing someone can produce similar numbers etc

I approached the ‘rotation day/date’ testing slightly differently…. I used the following code:

Code:

Parameters:

// EOM Random Day
EOMDay: From 0 to 20 Step 1 Def 0

Strategy: XSO_RTN
ExitRule: EndOfMonth[EOMDay] and (posrank > WRH or not canhold)

The code will rotate @ the end of the month PLUS the number of days that the “EOMDay” parameter is set to.

My testing/findings were similar to yours Trent….. the edge is to rotate @ the end of the month…. Rotating in the middle of the month saw performance fall away.

I also took a look at Weekly/Fortnightly rotational systems for the XSO (I didn’t test them exhaustively)…..however, thus far a Monthly rotational system approach (for me) produced the superior results….

[Author]

Posts