The following is from the RealCode website – I have just copied and pasted this here. Here is the header information that provides credit to the original programmer.
Here is the description of the Indicator via ProRealCode. Please check out the website for further information regarding the indicator and how to use it.
The RMI Trend Sniper indicator is designed to identify market trends and trading signals with remarkable precision.
This tool combines the analysis of the Relative Strength Index (RSI) with the Money Flow Index (MFI) and a unique approach to range-weighted moving average to offer a comprehensive perspective on market dynamics.
Configuration and Indicator Parameters
The RMI Trend Sniper allows users to adjust various parameters according to their trading needs, including:
RMI Length: Defines the calculation period for the RMI.
Positive and Negative Momentum (Positive above / Negative below): Sets thresholds to determine the strength of bullish and bearish trends.
Range MA Visualization (Show Range MA): Enables users to visualize the range-weighted moving average, along with color indications to quickly identify the current market trend.
Many of my clients ask me to convert indicators from different languages. One of my clients came across this from ProRealCode and asked me to convert for his MulitCharts. Pro Real code is very similar to EasyLanguage with a few exceptions. If you are savvy in EL, then I think you could pick up PRC quite easily. Here it is. It is a trend following indicator. It is one of a few that I could not find the Easylanguage equivalent so I thought I would provide it. Play around with it and let me know what you think. Again, all credit goes to:
if positive = 1 then begin rwma = rwma-band; r=0; g=188; b=212; end else if negative = 1 then begin rwma = rwma+band; r=255; g=82; b=82; end else rwma = 0;
//------------------------------------------------------------// //-----Calculate MA bands-------------------------------------// vars: mitop(0),mibot(0);
mitop = rwma+band20; mibot = rwma-band20;
plot1(mitop,"TOP"); plot2((mitop+mibot)/2,"TOP-BOT"); plot3((mitop+mibot)/2,"BOT-TOP"); plot4(mibot,"BOT"); if positive = 1 then begin plot5(rwma,"Pos",GREEN); noPlot(plot4); end; if negative =1 then begin plot6(rwma,"Neg",RED); noPlot(plot3); end;
Ignore the RGB Color Codes
Getting Creative to Shade Between Points on the Chart
TradeStation doesn’t provide an easy method to do shading, so you have to get a little creative. The plot TOP is of type Bar High with the thickest line possible. The plot TOP-BOT (bottom of top) is of type Bar Low. I like to increase transparency as much as possible to see what lies beneath the shading . The BOT-TOP (top of bottom) is Bar High and BOT is Bar Low. Pos and Neg are of type Point. I have colored them to be GREEN or RED.
If letting profits run is key to the success of a trend following approach, is there a way to take profit without diminishing returns?
Most trend following approaches win less than 40% of the time. So, the big profitable trades are what saves the day for this type of trading approach. However, it is pure pain to simply sit there and watch a large profit erode, just because the criteria to exit the trade takes many days to be met.
Three methods to take a profit on a Trend Following algorithm
Simple profit objective – take a profit at a multiple of market risk.
Trail a stop (% of ATR) after a profit level (% of ATR) is achieved.
Trail a stop (Donchian Channel) after a profit level (% of ATR) is achieved.
Use an input switch to determine which exit to incorporate
Inputs: initCapital(200000),rskAmt(.02), useMoneyManagement(False),exitLen(13), maxTradeLoss$(2500), // the following allows the user to pick // which exit to use // 1: pure profit objective // exit1ProfATRMult allows use to select // amount of profit in terms of ATR // 2: trailing stop 1 - the user can choose // the treshhold amount in terms of ATR // to be reached before trailing begins // 3: trailing stop 2 - the user can chose // the threshold amount in terms of ATR // to be reached before tailing begins whichExit(1), exit1ProfATRMult(3), exit2ThreshATRMult(2),exit2TrailATRMult(1), exit3ThreshATRMult(2),exit3ChanDays(5);
Exit switch and the parameters needed for each switch.
The switch determines which exit to use later in the code. Using inputs to allow the user to change via the interface also allows us to use an optimizer to search for the best combination of inputs. I used MultiCharts Portfolio Trader to optimize across a basket of 21 diverse markets. Here are the values I used for each exit switch.
MR = Market risk was defined as 2 X avgTrueRange(15).
Pure profit objective -Multiple from 2 to 10 in increments of 0.25. Take profit at entryPrice + or – Profit Multiple X MR
Trailing stop using MR – Profit Thresh Multiple from 2 to 4 in increments of 0.1. Trailing Stop Multiple from 1 to 4 in increments of 0.1.
Trailing stop using MR and Donchian Channel – Profit Thresh Multiple from 2 to 4 in increments of 0.1. Donchian length from 3 to 10 days.
//Reinvest profits? - uncomment the first line and comment out the second //workingCapital = Portfolio_Equity-Portfolio_OpenPositionProfit; workingCapital = initCapital;
if not(useMoneyManagement) then begin numContracts1 = 1; numContracts2 =1; end;
numContracts1 = maxList(numContracts1,intPortion(numContracts1)); {Round down to the nearest whole number} numContracts2 = MaxList(numContracts2,intPortion(numContracts1));
if c < buyLevel then buy numContracts1 contracts next bar at buyLevel stop; if c > shortLevel then Sellshort numContracts2 contracts next bar at shortLevel stop;
buytocover next bar at shortExit stop; Sell next bar at longExit stop;
vars: marketRiskPoints(0); marketRiskPoints = marketRisk/bigPointValue; if marketPosition = 1 then begin if whichExit = 1 then sell("Lxit-1") next bar at entryPrice + exit1ProfATRMult * marketRiskPoints limit; if whichExit = 2 then if maxcontractprofit > (exit2ThreshATRMult * marketRiskPoints ) * bigPointValue then sell("Lxit-2") next bar at entryPrice + maxContractProfit/bigPointValue - exit2TrailATRMult*marketRiskPoints stop; if whichExit = 3 then if maxcontractprofit > (exit3ThreshATRMult * marketRiskPoints ) * bigPointValue then sell("Lxit-3") next bar at lowest(l,exit3ChanDays) stop; end;
if marketPosition = -1 then begin if whichExit = 1 then buyToCover("Sxit-1") next bar at entryPrice - exit1ProfATRMult * marketRiskPoints limit; if whichExit = 2 then if maxcontractprofit > (exit2ThreshATRMult * marketRiskPoints ) * bigPointValue then buyToCover("Sxit-2") next bar at entryPrice - maxContractProfit/bigPointValue + exit2TrailATRMult*marketRiskPoints stop; if whichExit = 3 then if maxcontractprofit > (exit3ThreshATRMult * marketRiskPoints ) * bigPointValue then buyToCover("Sxit-3") next bar at highest(h,exit3ChanDays) stop; end;
setStopLoss(maxTradeLoss$);
Here’s the fun code from the complete listing.
vars: marketRiskPoints(0); marketRiskPoints = marketRisk/bigPointValue; if marketPosition = 1 then begin if whichExit = 1 then sell("Lxit-1") next bar at entryPrice + exit1ProfATRMult * marketRiskPoints limit; if whichExit = 2 then if maxContractProfit > (exit2ThreshATRMult * marketRiskPoints ) * bigPointValue then sell("Lxit-2") next bar at entryPrice + maxContractProfit/bigPointValue - exit2TrailATRMult*marketRiskPoints stop; if whichExit = 3 then if maxContractProfit > (exit3ThreshATRMult * marketRiskPoints ) * bigPointValue then sell("Lxit-3") next bar at lowest(l,exit3ChanDays) stop; end;
if marketPosition = -1 then begin if whichExit = 1 then buyToCover("Sxit-1") next bar at entryPrice - exit1ProfATRMult * marketRiskPoints limit; if whichExit = 2 then if maxContractProfit > (exit2ThreshATRMult * marketRiskPoints ) * bigPointValue then buyToCover("Sxit-2") next bar at entryPrice - maxContractProfit/bigPointValue + exit2TrailATRMult*marketRiskPoints stop; if whichExit = 3 then if maxContractProfit > (exit3ThreshATRMult * marketRiskPoints ) * bigPointValue then buyToCover("Sxit-3") next bar at highest(h,exit3ChanDays) stop; end;
The first exit is rather simple – just get out on a limit order at a nice profit level. The second and third exit mechanisms are a little more complicated. The key variable in the code is the maxContractProfit keyword. This value stores the highest level, from a long side perspective, reached during the life of the trade. If max profit exceeds the exit2ThreshATRMult, then trail the apex by exit2TrailATRMult. Let’s take a look at the math from a long side trade.
if maxContractProfit > (exit2ThreshATRMult * marketRiskPoints ) * bigPointValue
Since maxContractProfit is in dollar you must convert the exit2ThreshATRMult XmarketRiskPoints into dollars as well. If you review the full code listing you will see that I convert the dollar value, marketRisk, into points and store the value in marketRiskPoints. The conversion to dollars is accomplished by multiplying the product by bigPointValue.
sell("Lxit-2") next bar at
entryPrice + maxContractProfit / bigPointValue - exit2TrailATRMult * marketRiskPoints stop;
I know this looks complicated, so let’s break it down. Once I exceed a certain profit level, I calculate a trailing stop at the entryPrice plus the apex in price during the trade (maxContractProfit / bigPointValue) minus the exit2TrailATRMult X marketRiskPoints. If the price of the market keeps rising, so will the trailing stop. That last statement is not necessarily true, since the trailing stop is based on market volatility in terms of the ATR. If the market rises a slight amount, and the ATR increases more dramatically, then the trailing stop could actually move down. This might be what you want. Give the market more room in a noisier market. What could you do to ratchet this stop? Mind your dollars and your points in your calculations.
The third exit uses the same profit trigger, but simply installs an exit based on a shorter term Donchian channel. This is a trailing stop too, but it utilizes a chart point to help define the exit price.
Results of the three exits
Exit 1 – Pure Profit Objective
Take a profit on a limit order once profit reaches a multiple of market risk aka 2 X ATR(15).
The profit objective that proved to be the best was using a multiple of 7. A multiple of 10 basically negates the profit objective. With this system several profit objective multiples seemed to work.
Exit – 2 – Profit Threshold and Trailing Stop in terms of ATR or market risk
Trail a stop a multiple of ATR after a multiple of ATR in profit is reached.
3-D view of parameters
This strategy liked 3 multiples of ATR of profit before trailing and applying a multiple of 1.3 ATR as a stop.
Like I said in the video, watch out for 1.3 as you trailing amount multiple as it seems to be on a mountain ridge.
Exit – 3 – Profit Threshold in terms of ATR or market risk and a Donchain Channel trailing stop
Trail a stop using a Donchian Channel after a multiple of ATR in profit is reached. Here was a profit level is reached, incorporate a tailing stop at the lowest low or the highest high of N days back.
3-D view of parameters
Conclusion
The core strategy is just an 89-day Donchian Channel for entry and a 13-Day Donchian Channel for exit. The existing exit is a trailing exit and after I wrote this lengthy post, I started to think that a different strategy might be more appropriate. However, as you can see from the contour charts, using a trailing stop that is closer than a 13-day Donchian might be more productive. From this analysis you would be led to believe the ATR based profit and exit triggers (Exit #2) is superior. But this may not be the case for all strategies. I will leave this up to you to decide. Here is the benchmark performance analysis with just the core logic.
If you like this type of explanation and code, make sure you check at my latest book at amazon.com. Easing into EasyLanguage – Trend Following Edition.
I like to post something educational at least once a month. Sometimes, it’s difficult to come up with stuff to write about. Jeff really got me thinking with his Buy November… post. Check out his post “Riding the Market Waves: How to Surf Seasonal Trends to Trading Success.” Hopefully you have read his post and now have returned. As you know, the gist of his post was to buy in November and sell in May. Jeff was gracious enough to provide analysis, source and suggestions for improvement for this base strategy.
Why Change Jeff’s Code to a Framework?
I found Jeff’s post most intriguing, so the first think I start thinking about is how could I optimize the buy and sell months, a max loss, the three entry filters that he provided and in addition add a sell short option. If you have read my books, you know I like to develop frameworks for further research when I program an algorithm or strategy. Here is how I developed the framework:
Optimize the entry month from January to December or 1 to 12.
Optimize the exit month from January to December or 1 to 12.
Optimize to go long or go short or 1 to 2 (to go short any number other than 1 really).
currentMonth = Month(Date of tomorrow); If currentMonth = startMonth and mp = 0 and entriesThisMonth = 0 Then begin // a trade can only occur if canBuy is True - start month is active as // long as the filtering allows it. Until the filter is in alignment // keep looking for a trading during the ENTIRE startMonth if longOrShort = 1 and canBuy then entriesThisMonth = 1; if longOrShort = 1 and canBuy then buy("Buy Month") iShares contracts next bar at market; if longOrShort <> 1 and canShort then sellShort("Short Month") iShares contracts next bar at market; if longOrShort = -1 and canShort then entriesThisMonth = 1; end;
if CurrentMonth = endMonth Then begin if longOrShort = 1 then sell("L-xit Month") currentShares contracts next bar at market else buyToCover("S-xit Month") currentShares contracts next bar at market; end;
if mp = 1 then sell("l-xitMM") next bar at entryPrice - maxTradeRisk/bigPointValue stop; if mp =-1 then buyToCover("s-xitMM") next bar at entryPrice + maxTradeRisk/bigPointValue stop;
Snippet of the bones with extra flavor to enter and exit on certain months
You can see that I have provided the three inputs:
startMonth
endMonth
longOrShort
I get the currentMonth by peeking at the date of tomorrow and passing this date to the month function. If tomorrow is the first day of the month that I want to enter a long or short and the current market position (mp), and entriesThisMonth = 0, then a long or short position will be initiated. If the filters I describe a little later allow it, I know that I will be executing a trade tomorrow, and I can go ahead assign a 1 to entries this month. Why do I do this? Just wait and you will see. Long entries depend on the variable longOrShort being equal to 1 and the toggle canBuy set to True. What is canBuy. Just wait and you will see. The sell short is similar, but conversely longOrShort needs to not equal 1. In addition, canShort needs to be true too.
If the currentMonth = endMonth, then based on the market position a sell or a buy to cover will be executed.
How to add filters to Determine canBuy and canShort
if useMACDFilter = 1 then begin canBuy = MACDVal > MACDLevel; canShort = MACDVal < MACDLevel; end;
if useMAFilter = 1 then begin canBuy = close > MAVal and canBuy; canShort = close < MAVal and canShort; end;
if useRSIFilter = 1 then begin canBuy = RSIVal > RSILevel and canBuy; canShort = RSIVal < RSILevel and canShort; end;
Calculate Filter Components and then test them
You cannot optimize a True to False toggle, but you can optimize 0 for off and 1 for on. Here the useFilterName inputs are initially set to 0 or off. Each filter indicator has respective inputs so that the filters can be calculated with the user’s input. If the filters are equal to one, then a test to turn canBuy and canShort to on or off is laid out in the code. Each test depends on either the state of price compared to the indicator value, or the indicator’s relationship to a user defined level or value.
Will this code test all the combination of the filters?
Yes! F1 is Filter 1 and F2 is Filter 2 and F3 is Filter 3. By optimizing each filter from 0 to 1, you will span this search space.
F1 = On; F2 = Off; F3 = Off
F1 = On; F2 = On; F3 = Off
F1 = On; F2 = On; F3 = On
F1 = Off; F2 = On; F3 = Off
F1 = Off; F2 = On; F3 = On
F1 = Off; F2 = Off: F3 = On
F1 = On; F2 = Off; F3 = On
You will notice I initially set canBuy and canShort to True and then turn them off if an offending filter occurs. Notice how I AND the results for Filter 2 and Filter 3 with canBuy or canShort. Doing this allows me to cascade the filter combinations. I do want to test when all filters are in alignment. In other words, they must all be True to initiate a position.
Should the Filters be Active During the Entire Entry Month?
What if the first day of the month arrives and you can’t initiate a trade due to a conflict of one of the filters. Should we allow a trade later in the entry month if the filters align properly? If we are testing 25 years of history and allow for entry later on in the month, we could definitely generate as close to 25 trades as possible. This line of code keeps the potential of a trade open for the entire month.
// only set entriesThisMonth to true // when all the stars align - might enter a long // trade on the last day of the month
if longOrShort = 1 and canBuy then entriesThisMonth = 1;
Keep the entire start month active
Some Tricky Code
I wanted to allow a money management exit on a contract basis. I had to devise some code that would not allow me to reenter the startMonth if I got stopped out prematurely in the startMonth (the same month as entry.)
if entriesThisMonth = 1 and monthOfTomorrow <> startMonth then entriesThisMonth = 0;
This code resets entriesThisMonth
If a position is initiated, I know entriesThisMonth will be set to one. If I enter into another month that is not the startMonth then entriesThisMonth is set to 0. This prevents reentry in case we get stopped out in the same month we initially enter a position. In other words, entriesThisMonth stays one until a new month is observed. And we can’t enter when entriesThisMonth is equal to one.
if entriesThisMonth = 1 and monthOfTomorrow <> startMonth then entriesThisMonth = 0;
if useMACDFilter = 1 then begin canBuy = MACDVal > MACDLevel; canShort = MACDVal < MACDLevel; end;
if useMAFilter = 1 then begin canBuy = close > MAVal and canBuy; canShort = close < MAVal and canShort; end;
if useRSIFilter = 1 then begin canBuy = RSIVal > RSILevel and canBuy; canShort = RSIVal < RSILevel and canShort; end;
currentMonth = Month(Date of tomorrow); //print(d," ",currentMonth," ",startMonth," ",entriesThisMonth); If currentMonth = startMonth and mp = 0 and entriesThisMonth = 0 Then begin // print(d," ",currentMonth," ",canBuy); if longOrShort = 1 and canBuy then entriesThisMonth = 1; if longOrShort = 1 and canBuy then buy("Buy Month") iShares contracts next bar at market; if longOrShort <> 1 and canShort then sellShort("Short Month") iShares contracts next bar at market; if longOrShort = -1 and canShort then entriesThisMonth = 1; end;
if CurrentMonth = endMonth Then begin if longOrShort = 1 then sell("L-xit Month") currentShares contracts next bar at market else buyToCover("S-xit Month") currentShares contracts next bar at market; end;
if mp = 1 then sell("l-xitMM") next bar at entryPrice - maxTradeRisk/bigPointValue stop; if mp =-1 then buyToCover("s-xitMM") next bar at entryPrice + maxTradeRisk/bigPointValue stop;
Complete Code Framework
Here is the best equity curve I uncovered when I optimized the startMonth from 1 to 12 and the endMonth from 1 to 12 and the maxTradeRisk per contract and the three entry filters. Entering in November when the moving average filter aligns and exiting on the first day of August and risking $5,500 per contract produced this equity curve.
The test returned what would basically be similar to a buy and hold scenario; the difference being you only hold the trade between seven and eight months of the year and risk only $5,500 per contract. If you get stopped out, you wait until November to get back in – whenever the moving average filter allows. Net profit to draw down ratio is north of 4.0.
Last Comment
If I optimize from 1 to 12 for the start month and 1 to 12 for end month, will this not cause an error? What if the two values equal? I mean I can’t enter and exit in the same month – a one-day trade? You could make the code smarter, but it doesn’t matter. As a user you will know better than to use the same number and the optimizer will test the combination with the same number, but the results will fall off the table. In this case, error trapping doesn’t prevent a necessarily unwanted or dangerous scenario.
Multiple trading decisions based on “logic” may not add to the bottom line
In this post, I will present a trend following system that uses four exit techniques. These techniques are based on experience and also logic. The problem with using multiple exit techniques is that it is difficult to see the synergy that is generated from all the moving parts. Pruning your algorithm may help cut down on invisible redundancy and opportunities to over curve fit. The trading strategy I will be presenting will use a very popular entry technique overlaid with trade risk compression.
Entry logic
Long:
Criteria #1: Penetration of the closing price above an 85 day (closing prices) and 1.5X standard deviation-based Bollinger Band.
Criteria #2: The mid-band or moving average must be increasing for the past three consecutive days.
Criteria #3: The trade risk (1.5X standard deviation) must be less than 3 X average true range for the past twenty days and also must be less than $4,500.
Risk is initially defined by the standard deviation of the market but is then compared to $4,500. If the trade risk is less than $4,500, then a trade is entered. I am allowing the market movement to define risk, but I am putting a ceiling on it if necessary.
Short:
Criteria #1: Penetration of the closing price below an 85 day (closing prices) and 1.5X standard deviation-based Bollinger Band.
Criteria #2: The mid-band or moving average must be decreasing for the past three consecutive days.
Criteria #3: Same as criteria #3 on the long side
Exit Logic
Exit #1: Like any Bollinger Band strategy, the mid band or moving average is the initial exit point. This exit must be included in this particular strategy, because it allows exits at profitable levels and works synergistically with the entry technique.
Exit #2: Fixed $ stop loss ($3,000)
Exit #3: The mid-band must be decreasing for three consecutive days and today’s close must be below the entry price.
Exit #4: Todays true range must be greater than 3X average true range for the past twenty days, and today’s close is below yesterday’s, and yesterday’s close must be below the prior days.
Here is the logic of exits #2 through exit #4. With longer term trend following system, risk can increase quickly during a trade and capping the maximum loss to $3,000 can help in extreme situations. If the mid-band starts to move down for three consecutive days and the trade is underwater, then the trade probably should be aborted. If you have a very wide bar and the market has closed twice against the trade, there is a good chance the trade should be aborted.
Short exits use the same logic but in reverse. The close must close below the midband, or a $3,000 maximum loss, or three bars where each moving average is greater than the one before, or a wide bar and two consecutive up closes.
Here is the logic in PowerLanguage/EasyLanguage that includes the which exit seletor.
if whichExit = 1 then permString = "1"; if whichExit = 2 then permString = "1,2"; if whichExit = 3 then permString = "1,3"; if whichExit = 4 then permString = "2"; if whichExit = 5 then permString = "2,3"; if whichExit = 6 then permString = "3"; if whichExit = 7 then permString = "1,2,3";
{Long Entry:} If (MarketPosition = 0) and Close crosses above upperBand and slopeUp and (tradeRisk < initialRisk*maxNATRLossMult and tradeRisk<maxEntryRisk$/bigPointValue) then begin Buy ("LE") Next Bar at Market; End;
{Short Entry:}
If (MarketPosition = 0) and slopeDn and Close crosses below lowerBand and (tradeRisk < initialRisk*maxNATRLossMult and tradeRisk<maxEntryRisk$/bigPointValue) then begin Sell Short ("SE") Next Bar at Market; End;
{Long Exits:}
if marketPosition = 1 Then Begin longLoss = initialRisk * maxNATRLossMult; longLoss = minList(longLoss,maxTradeLoss$/bigPointValue);
If Close < sma then Sell ("LX Stop") Next Bar at Market;;
if inStr(permString,"1") > 0 then sell("LX MaxL") next bar at entryPrice - longLoss stop;
if inStr(permString,"2") > 0 then If sma < sma[1] and sma[1] < sma[2] and sma[2] < sma[3] and close < entryPrice then Sell ("LX MA") Next Bar at Market; if inStr(permString,"3") > 0 then If TrueRange > largeATR and close < close[1] and close[1] < close[2] then Sell ("LX ATR") Next Bar at Market; end;
{Short Exit:}
If (MarketPosition = -1) Then Begin
shortLoss = initialRisk * maxNATRLossMult; shortLoss = minList(shortLoss,maxTradeLoss$/bigPointValue); if Close > sma then Buy to Cover ("SX Stop") Next Bar at Market;
if inStr(permString,"1") > 0 then buyToCover("SX MaxL") next bar at entryPrice + shortLoss stop;
if inStr(permString,"2") > 0 then If sma > sma[1] and sma[1] > sma[2] and sma[2] > sma[3] and close > entryPrice then Buy to Cover ("SX MA") Next Bar at Market; if inStr(permString,"3") > 0 then If TrueRange > largeAtr and close > close[1] and close[1] > close[2] then Buy to Cover ("SX ATR") Next Bar at Market; end;
Trend following with exit selector
Please note that I modified the code from my original by forcing the close to cross above or below the Bollinger Bands. There is a slight chance that one of the exits could get you out of a trade outside of the bands, and this could potentially cause and automatic re-entry in the same direction at the same price. Forcing a crossing, makes sure the market is currently within the bands’ boundaries.
This code has an input that will allow the user to select which combination of exits to use.
Since we have three exits, and we want to evaluate all the combinations of each exit separately, taken two of the exits and finally all the exits, we will need to rely on a combinatorial table. In long form, here are the combinations:
3 objects in our combinations of exit 1, exit 2, exit 3
one – 1
two – 1,2
three – 1,3
four – 2
five – 2,3
six – 3
seven – 1,2,3
There are a total of seven different combinations. Given the small set, we can effectively hard-code this using string manipulation to create a combinatorial table. For larger sets, you may find my post on the Pattern Smasher beneficial. A robust programming language like Easy/PowerLanguage offers extensive libraries for string manipulation. The inStrstring function, for instance, identifies the starting position of a substring within a larger string. When keyed to the whichExit input, I can dynamically recreate the various combinations using string values.
if whichExit = 1 then permString = “1”
if whichExit = 2 then permString= “1,2”
if whichExit = 3 then permString = “1,2,3”
etc…
As I optimize from one to seven, permString will dynamically change its value, representing different rows in the table. For my exit logic, I simply check if the enumerated string value corresponding to each exit is present within the string.
if inStr(permString,"1") > 0 then sell("LX MaxL") next bar at entryPrice - longLoss stop; if inStr(permString,"2") > 0 then If sma < sma[1] and sma[1] < sma[2] and sma[2] < sma[3] and close < entryPrice then Sell ("LX MA") Next Bar at Market; if inStr(permString,"3") > 0 then If TrueRange > largeATR and close < close[1] and close[1] < close[2] then Sell ("LX ATR") Next Bar at Market;
Using inStr to see if the current whichExit input applies
When permString = “1,2,3” then all exits are used. If permString = “1,2”, then only the first two exits are utilized. Now all we need to do is optimize whichExit from 1 to 7. Let’s see what happens:
The best combination of exits was “3”. Remember 3 is the permString that = “1,3” – this combination includes the money management loss exit, and the wide bar against position exit. It only slightly improved overall profitability instead of using all the exits – combo #7. In reality, just using the max loss stop wouldn’t be a bad way to go either. Occam uses his razor to shave away unnecessary complexities again!
If you like this code, you should check out the Summer Special at my digital store. I showcase over ten more trend-following algorithms with different entry and exit logic constructs. These other algorithms are derived from the best Trend Following “Masters” of the twentieth century. IMHO!
Here is a video you can watch that goes over the core of this trading strategy.
In May of 2018 Morgan Stanley presented a report from their research department. The report was written by Tony Small and Matthew Hornbach. The information presented validated the idea of seasonality in the markets. The writers/researchers gathered all the data going back to 1984 on the ten-year futures and all the federal holidays going back over the same span of time. They then analyzed either going long or short M days prior to the holiday and exiting N days before the holidays. They also did the same thing after the holiday – entering M days after and exiting N days after. The boundary was set to five days before and after. This report was sent to me by one of my clients. The conclusion of the article was that there seemed to be a seasonality component to the days prior and after a major holiday. And that it seemed this component did indeed provide a technical advantage (on the surface.) Here is their conclusion.
“Given the risk of data mining, investors should accept this analysis with some degree of caution,” Small and Hornbach said. “There is no guarantee that historical seasonality and past price performance will continue in the future.”
How would one test this idea on their own?
Tools needed:
Python with NumPy installed.
An AI chatbot such as ChatGPT.
Access to TY futures data going back to 1984 (actual non-Panama adjusted data would be preferable.)
A testing platform that allows future leak such as George’s own TradingSimula-18. Excel would work too but would require a bunch of work.
Some programming knowledge.
Create output for all of the federal holidays going back to January 1984. This list must also include Good Fridays. This list should have two fields – the date and the name of the holiday.
TS-18 came in handy because I read the file that was created from step 1 and whenever I came across or spanned a holiday date, I created a loop that calculated the ROC for the prior five days and also for the five days that followed. I created a nomenclature to quickly recognize the ROC span.
B54 – ROC between 5 days before and 4 days before – 1 day
B53 – ROC between 5 days before and 3 days before – 2 days
B52 – ROC between 5 days before and 2 days before – 3 days
B51 – ROC between 5 days before and 1 days before – 4 days
B43 – ROC between 4 days before and 3 days before – 1 day
B42 – ROC between 4 days before and 2 days before – 2 days
B41 – ROC between 4 days before and 1 days before – 3 days
B32 – ROC between 3 days before and 2 days before – 1 day
B31 – ROC between 3 days before and 1 days before – 2 days
B21 – ROC between 2 days before and 1 days before – 1 day
A12 – ROC between 1 days after and 2 days after – 1 day
A13 – ROC between 1 days after and 3 days after – 2 days
A14 – ROC between 1 days after and 4 days after – 3 days
A15 – ROC between 1 days after and 5 days after – 4 days
A23 – ROC between 2 days after and 3 days after – 1 day
A24 – ROC between 2 days after and 4 days after – 2 days
A25 – ROC between 2 days after and 5 days after – 3 days
A34 – ROC between 3 days after and 4 days after – 1 day
A35 – ROC between 3 days after and 5 days after – 2 days
A45 – ROC between 4 days after and 5 days after – 1 day
This process created a file that looked like this:
With this data I summed up each ROC calculation (B54 thru A45). From this you could pick an entry and exit day combination. The best results were wrapped around Memorial Day. Here was where I ran into a small but highly aggravating scenario. Most of the holidays had similar numbers, but there were a few that had some really strange values. I knew I couldn’t use regular adjusted futures data, because many times these values can go below zero and when doing division with these price adjustments, the values are simply not accurate. So, I used continuous non adjusted data, but ran into a problem with the rollover gap. Some of the holidays occurred really close to rollover dates. The calculations that bridged a rollover was not accurate. I then remembered Pinnacle data also includes Ratio Adjusted Data or RAD. I applied the looping algorithm to this data, and it SEEMED to fix the problem.
I was able to pick a B(n,m) or A(m,n) for each market. If the magnitude of ROC was sufficiently negative, you could use the dates to short the market.
ChatGPT and Python and Numpy to the rescue
I asked ChatGPT to provide python code to generate a list of all federal holidays from 1984.
from pandas.tseries.holiday import USFederalHolidayCalendar from datetime import datetime,timedelta import numpy as np # Create a calendar for U.S. federal holidays cal = USFederalHolidayCalendar()
# Get the holidays for the year 2014 holidays_2014 = cal.holidays(start='1984-01-01', end='2024-12-31').to_pydatetime()
federalHolidays = [] date_list = holidays_2014.astype(datetime).tolist() for n in range(len(date_list)): dateString = f'{date_list[n]:%Y%m%d}' federalHolidays.append(int(dateString))
Create a list of federal holidays
This worked great, but I had to convert the NumPy datetime construct to a string. I like to keep things simple. You will see this in the code. I started to get to work on the second part of the task when I discovered there were no dates for GOOD FRIDAYS – argh! ChatGPT to rescue once again.
def good_friday_dates(start_year, end_year): good_friday_dates = [] for year in range(start_year, end_year + 1): # Calculate the date of Easter Sunday for the given year easter_sunday = calculate_easter_date(year)
# Good Friday is two days before Easter Sunday good_friday = easter_sunday - timedelta(days=2)
# Add the Good Friday date to the list good_friday_dates.append(good_friday)
return good_friday_dates
def calculate_easter_date(year): # Algorithm to calculate the date of Easter Sunday a = year % 19 b = year // 100 c = year % 100 d = b // 4 e = b % 4 f = (b + 8) // 25 g = (b - f + 1) // 3 h = (19 * a + b - d - g + 15) % 30 i = c // 4 k = c % 4 l = (32 + 2 * e + 2 * i - h - k) % 7 m = (a + 11 * h + 22 * l) // 451 month = (h + l - 7 * m + 114) // 31 day = ((h + l - 7 * m + 114) % 31) + 1 easter_date = datetime(year, month, day) return easter_date
# Generate Good Friday dates from 1984 to 2024 good_friday_dates_1984_to_2024 = good_friday_dates(1984, 2024)
Hope this code is right for Good Fridays
Good Friday, as Easter, is all over the map. Tomorrow is Good Friday. The code looks pretty gross, so I just accepted it. It may not be 100% accurate, but if ChatGPT says so…. Once I had a list of all holidays, I was able to start cooking (MLK was added in 1986 and Juneteenth in 2021.) Since Juneteenth is relatively new it did not offer a statistically significant number of observations.
Future Leak comes in Handy.
Every quant needs some software that will look through data and do some calculations. I did this project with EasyLanguage, but it was a little difficult. I had to do a two-pass process (well I did the same with Python too.) I first created an indicator that imported the holiday dates and then outputted the close (or open of next bar) for close[5], close[4], close[3], close[2], close[1] and then waited 1, 2, 3, 4 and 5 bars after the date and printed out those respective closing prices. I did not do this step in EasyLanguage. I actually create EasyLanguage as my output. Here is what it looked like:
Future leak allows you to peak into the future and this comes in super handy when doing research like this. Here is some python code in TS-18 that does all these calculations in one sweep.
# The date of the holiday and the holiday name are stored in lists # Each Holiday has its own date and 20 ROC calculations # These calculations are stored in lists as well tempDate = int(extraData[extraCnt][0]) #first field in the csv file whichHoliday = extraData[extraCnt][1] #second field in the csv file if date[D] == tempDate or (date[D] > tempDate and date[D1] < tempDate): foundJ = 99 for j in range(12): if whichHoliday == listOfHolidayClass[j].holidayName: foundJ = j listOfHolidayClass[foundJ].holidayDates.append(tempDate); for j in range(-5,-1): #Before Holiday for k in range(j+1,0): denom = close[D+j] listOfHolidayClass[foundJ].rocList.append((close[D+k] - close[D+j])/denom) for j in range(0,4): #After Holiday - here is the future leak for k in range(j+1,5): denom = close[D+j] listOfHolidayClass[foundJ].rocList.append((close[D+k] - close[D+j])/denom) extraCnt = extraCnt + 1
Python code using future leak to calculate the 20 ROC from before and after holiday
I then printed this out to a csv file and imported into Excel (see above) and found out the best combination of days for each holiday. Now that I had the B(n,m) or the A(m,n) values, I need a process to tell TS-18 which day to buy/short and exit. Here is some code that, again uses future leak, to print out the five dates before the holiday and the five dates after the holiday.
tempDate = int(extraData[extraCnt][0]) whichHoliday = extraData[extraCnt][1] if date[D] == tempDate or (date[D] > tempDate and date[D1] < tempDate): for j in range(12): if whichHoliday == listOfHolidayClass[j].holidayName: foundJ = j print(date[D],end=',') print(whichHoliday,end=',') for j in range(-5,6): print(date[D+j],end=',') print("",end = '\n') extraCnt = extraCnt + 1
# Here is what the file looked like 19840103,NewYear,19831223,19831227,19831228,19831229,19831230,19840103,19840104,19840105,19840106,19840109,19840110, 19840221,PresidentsDay,19840213,19840214,19840215,19840216,19840217,19840221,19840222,19840223,19840224,19840227,19840228, 19840423,GoodFriday,19840413,19840416,19840417,19840418,19840419,19840423,19840424,19840425,19840426,19840427,19840430, 19840529,MemorialDay,19840521,19840522,19840523,19840524,19840525,19840529,19840530,19840531,19840601,19840604,19840605, 19840705,July4th,19840627,19840628,19840629,19840702,19840703,19840705,19840706,19840709,19840710,19840711,19840712, 19840904,LaborDay,19840827,19840828,19840829,19840830,19840831,19840904,19840905,19840906,19840907,19840910,19840911, 19841008,ColumbusDay,19841001,19841002,19841003,19841004,19841005,19841008,19841009,19841010,19841011,19841012,19841015, 19841112,VeteransDay,19841105,19841106,19841107,19841108,19841109,19841112,19841113,19841114,19841115,19841116,19841119, 19841123,Thanksgiving,19841115,19841116,19841119,19841120,19841121,19841123,19841126,19841127,19841128,19841129,19841130,
Create the dates that occur in the date B4 and after holiday
Now read the data in and pick how many days before to b/s and before to exit or after to b/s and to exit
#structure of holidayDatesData list - all strings # 0.) Holiday Date # 1.) Holiday Name # 2.) 5-Before # 3.) 4-Before # 4.) 3-Before # 5.) 2-Before # 6.) 1-Before # 7.) 0-Before/After # 8.) 1-After # 9.) 2-After # 10.) 3-After # 11.) 4-After # 12.) 5-After #Below I pick 1 day after to buy and 4 days after to exit [8,11] for j in range(numHolidayDates): if holidayDatesData[j][1] == "MemorialDay": holidayBuyDates.append(int(holidayDatesData[j][8])) holidayXitDates.append(int(holidayDatesData[j][11]))
# Okay Let's put in some logic to create a long position if not(long) and canTrade and date[D] == holidayBuyDates[gfCnt]: price = close[D] tradeName = "Hol-A1Buy" posSize = 1 tradeTicket.append([buy,tradeName,posSize,price,mkt]) # Long Exits if long and canTrade and date[D] == holidayXitDates[gfCnt]: price = longExit tradeName = "Hol-A4Xit" tradeTicket.append([exitLong,tradeName,curShares,price,mkt]) gfCnt = gfCnt + 1
Here are the results for the Morgan Stanley analysis in 2018
My analysis covered the same period plus all of 2018, 2019, 2020, 2021, 2022, and 2023. My combos were very similar in most cases, but the last few years moved the needle a little bit. However, the results still showed a technical edge.
The Fixed Fractional position sizing scheme is the most popular, so why does it need fixed?
Problems solved with Fixed Fractional:
Efficient usage of trading capital
Trade size normalization between different futures contracts
Trade size normalization across different market environments
These are very good reasons why you should use positions sizing. Problem #2 doesn’t apply if you are only trading one market. This sounds idyllic, right? It solves these two problems, but it introduces a rather bothersome side effect – huge draw down. Well, huge draw down in absolute terms. Draw downs when using a fixed fractional approach are proportional to the prior run up. If you make a ton of money on a prior trade, then your position sizing reflects that big blip in the equity curve. So, if you have a large loser following a large winner, the draw down will be a function of the run up. In most cases, a winning trading system using fixed fractional position sizing will scale profit up as well as draw down. A professional money manager will look at the profit to draw down ratio instead of the absolute draw down value. The efficient use of capital will reflect a smaller position size after a draw down, so that is good right? It is unless you believe in a Martingale betting algorithm – double up on losses and halve winners. Are we just stuck with large “absolute” draw downs when using this size scheme?
Possible solutions to fixing Fixed Fractional (FF)
The first thing you can do is risk less than the industry standard 2% per trade. Using 1% will cause equity to grow at a slower rate and also reduce the inevitable draw down. But this doesn’t really solve the problem as we are giving up the upside. And that might be okay with you. Profit will increase and you are using an algorithm for size normalization. In this blog I am going to propose a trading equity adjustment feature while using FF. What if we act like money managers, and you should even if you are trading your own personal money, and at the end of the year or month we take a little off the table (theoretically – we are not removing funds from the account just from the position sizing calculation) that is if there is any extra on the table. This way we are getting the benefit of FF while removing a portion of the compounding effect, which reduces our allocation for the next time interval. How do you program such a thing? Well first off let’s code up the FF scheme.
Nothing new here. Simply multiply tradingCapital by the riskPerTrade (1 or 2%) and then divide by a formula that defines current and inherent market risk. This is where you can become very creative. You could risk the distance between entry and exit if you know those values ahead of time or you can use a value in terms of the current market. Here I have chosen the 30-day average true range. This value gives a value that predicts the market movement into the future. However, this value only gives the expected market movement for a short period of time into the future. You could us a multiplier since you will probably remain in a trade for more than a few days – that is if you are trying to capture the trend. In my experiment I just use one as my multiplier.
Capture and store the prior year/month NetProfit
When I come up with a trading idea I usually just jump in and program it. I don’t usually take time to see if Easy Language already provides a solution for my problem. Many hours have been used to reinvent the wheel, which isn’t always a bad thing. So, I try to take time and search the functions to see if the wheel already exists. This time it looks like I need to create the wheel. I will show the code first and then explain afterward.
if useAllocateYearly then begin value1 = year(d); value2 = year(d[1]); end;
if useAllocateMonthly then //remember make sure your array is 12XNumYears begin value1 = month(d); value2 = month(d[1]); end;
if useAllocateYearly or useAllocateMonthly then begin if value1 <> value2 then begin if ypIndex > 0 then yearProfit[ypIndex] = prevNetProfit - snapShotNetProfit[ypIndex-1] else yearProfit[ypIndex] = prevNetProfit;
Capture either the prior years or months net profit
I wanted to test the idea of profit retention on a monthly and yearly basis to see if it made a difference. I also wanted to just use the vanilla version of FF. The use of Arrays may not be necessary, but I didn’t know ahead of time. When you program on the fly, which is also called “ad hoc” programming you create first and then refine later. Many times, the “ad hoc” version turns out to be the best approach but may not be the most efficient. Like writing a book, many times your code needs revisions. When applying a study or strategy that uses dates to a chart, you don’t know exactly when the data starts so you always need to assume you are starting in the middle of a year. If you are storing yearly data into an array, make sure you dimension you array sufficiently. You will need 12X the number of years as the size you need to dimension your array if you want to store monthly data.
//250 element array will contain more than 20 years of monthly data //You could increase these if you like just to be safe arrays: yearProfit[250](0),snapShotNetProfit[250](0); //Remember you dimension you arrray variable first and then //Pass it a value that you want to initiate all the values //in the array to equal vars: ypIndex(0);
Dimension and Initiate Your Arrays
The first thing we need to do is capture the beginning of the year or month. We can do this by using the year and month function. If the current month or year value is not the same as the prior day’s month or year value, then we know we crossed the respective timeline boundary. We are using two arrays, snapShotNetProfit and yearProfit (to save time I use this array to store monthlty values as well, when that option is chosen) and a single array index ypIndex. If we have crossed the time boundary, the first thing we need to do is capture the EasyLanguage functionNetProfit’s value. NetProfit keeps track of the cumulative closed out trade profits and losses. Going forward in this description I am going to refer to a yearly reallocation. If it’s the first year, the ypIndex will be zero, and in turn the first year’s profit will be the same as netProfit. We store netProfit in the yearProfit array at the ypIndex location. Since we are in a new year, we take a snapshot of netProfit and store it in the snapShotNetProfit array at the same ypIndex location. You will notice I use the variable prevNetProfit in the code for netProfit. Here is where the devil is in the details. Since we are comparing today’s year value with yesterday’s year value and when they are different, we are already inside the new year, so we need to know yesterday’s netProfit. Before you say it, you can’t pass netProfit a variable for prior values; you know like netProfit(1) or netProfit[1] – this is a function that has no historic values, but you can record the prior day’s value by using our own prevNetProfit variable. Now we need to calculate the tradingCapitalAdjustment. The first thing we do is assign the variable the value held in yearProfit[ypIndex]. We then test the yearProfit[ypIndex] value to see if it is positive. If it is, then we multiply it by (1-removePerProfit). If you want to take 75% of the prior year’s profit off the table, then you would multiply the prior year’s profit by 25%. Let’s say you make $10,000 and you want to remove $7,500, then all you do is multiply $10,000 by 25%. If the prior year’s netProfit is a loss, then this value flows directly through the code to the position sizing calculation (auto deallocation on a losing year). If not, the adjusted profit portion of funds are deallocated in the position sizing equation.
The next time we encounter a new year, then we know this is the second year in our data stream, so we need to subtract last year’s snapshot of netProfit (or prevNetProfit) from the current netProfit. This will give us the change in the yearly net profit. We stuff this information into the yearProfit array. The snapShotNetProfit is stuffed with the current prevNetProfit. ypIndex is incremented every time we encounter a new year. Notice how I increment the ypIndex – it is incremented after all the calculations in the new year. The tradingCapitalAdjustment is then calculated with the latest information.
Here is a table of how the tradingCapital and profit retention adjustment are calculated. A yearly profit adjustment only takes place after a profitable year. A losing year passes without adjustment.
All tests were carried out on the trend friendly crude oil futures with no execution costs from 2006 thru 2/28/2204.
See how money is removed from the allocation model after winning years.
Here are some optimization tests with 75% profit retention on yearly and monthly intervals.
Yearly First-
Now Monthly-
What if we didn’t reallocate on any specific interval?
Huge drawdowns with very little change in total profit.
Add some trade management into the mix.
Here we optimize a protective stop and a break-even level to see if we can juice the results. All the trade management is on a positionbasis.
Are we really using our capital in the most efficient manner?
If we retain profit, should we remove some of the loss form the position sizing engine as well. All the tests I performed retained profit from the position size calculations. I let the loss go full bore into the calculation. This is a very risk averse approach. Why don’t I retain 25% of losses and deduct that amount from the yearly loss and feed that into the position sizing engine. This will be less risk averse – let’s see what it does.
Not as good. But I could spend a week working different permutations and optimization sessions.
Are you wondering what Trend Following System I was using as the foundation of this strategy? I used EasyLanguage’s Linear Regression function to create buy and short levels. Here is the very simple code.
//Basically I am buying/shorting on the change of the linear regression slope //Also I have a volatility filter but it really isn't used If value2 >=0 and value2[1] < 0 and avgTrueRange(30)*bigPointValue < 10000 then buy positionSize contracts next bar at market; If value2 <=0 and value2[1] > 0 and avgTrueRange(30)*bigPointValue < 10000 then sellShort positionSize contracts next bar at market;
mp = marketPosition;
//I also have incorporated a 3XATR(30) disaster stop if mp = 1 and c <= entryPrice - 3 * avgTrueRange(30) then sell next bar at market; if mp = -1 and c >= entryPrice + 3 * avgTrueRange(30) then buyToCover next bar at market
If you want to see some more Trend Following models and their codes in EasyLanguage and TS-18 Python check out my TrendFollowing Guide and Kit.
Dollar Cost Averaging Algorithm – Buy X amount every other Monday!
I am not going to get into this controversial approach to trading. But in many cases, you have to do this because of the limitations of your retirement plan. Hey if you get free matching dough, then what can you say.
Check this out!
if dayOfWeek(d of tomorrow)< dayOfWeek(d) Then begin toggle = not(toggle); if toggle then buy dollarInvestment/close shares next bar at open; end;
Toggle every other Monday ON
Here I use a Boolean typed variable – toggle. Whenever it is the first day of the week, turn the toggle on or off. Its new state becomes the opposite if its old state. On-Off-On-Off – buy whenever the toggle is On or True. See how I determined if it was the first day of the week; whenever tomorrow’s day of the week is less than today’s day of the week, we must be in a new week. Monday = 1 and Friday = 5.
Allow partial liquidation on certain days of the year.
Here I use arrays to set up a few days to liquidate a fractional part of the entire holdings.
value1 = d + 19000000; if sellDates[cnt] = value1 then begin sell sellAmounts[cnt]/close shares total next bar at open; cnt = cnt + 1; end;
Notice the word TOTAL in the order directive.
You can use this as reference on how to declare an array and assign the elements an initial value. Initially, sellDates is an array that contains 20 zeros, and sellAmounts is an array that contains 20 zeros as well. Load these arrays with the dates and the dollar amounts that want to execute a partial liquidation. Be careful with using Easylanguage’s Date. It is in the form YYYMMDD – todays date December 28, 2023, would be represented by 1231228. All you need to do is add 19000000 to Date to get YYYYMMDD format. You could use a function to help out here, but why. When the d + 19000000 equals the first date in the sellDates[1] array, then a market sell order to sell sellAmounts[1]/close shares total is issued. The array index cnt is incremented. Notice the order directive.
sell X sharestotal next bar at market;
If you don’t use the keyword total, then all the shares will be liquidated.
To create a complete equity curve, you will want to liquidate all the shares at some date near the end of the chart. This is used as input as well as the amount of dollars to invest each time.
//Demonstation of Dollar Cost Averaging //Buy $1000 shares every two weeks //Then liquidate a specific $amount on certain days //of the year
value1 = d + 19000000; if sellDates[cnt] = value1 then begin sell sellAmounts[cnt]/close shares total next bar at open; cnt = cnt + 1; end;
if dayOfWeek(d of tomorrow)< dayOfWeek(d) Then begin toggle = not(toggle); if toggle then buy dollarInvestment/close shares next bar at open; end;
if d + 19000000 = settleDate Then sell next bar at open;
A cool looking chart.
Allow Pyramiding
Working with Data2
I work with many charts that have a minute bar chart as Data1 and a daily bar as Data2. And always forget the difference between:
Close of Data2 and Close[1] of Data2
24 hour regular session used here 1231214 1705 first bar of day - close of data2 4774.00 close[1] of data2 4760.75 1231214 1710 second bar of day - close of data2 4774.00 close[1] of data2 4760.75 1231215 1555 next to last bar of day - close of data2 4774.00 close[1] of data2 4760.75 1231215 1600 last bar of day - close of data2 4768.00 close[1] of data2 4774.00
Up to the last bar of the current trading day the open, high, low, close of data2 will reflect the prior day’s values. On the last bar of the trading day – these values will be updated with today’s values.
Learn how to constrain trading between a Start and End Time – not so “easy-peasy”
Why waste time on this?
Is Time > StartTime and Time <= EndTime then… Right?
This is definitely valid when EndTime > StartTime. But what happens when EndTime < StartTime. Meaning that you start trading yesterday, prior to midnight, and end trading after midnight (today.) Many readers of my blog know I have addressed this issue before and created some simple equations to help facilitate trading around midnight. The lines of code I have presented work most of the time. Remember when the ES used to close at 4:15 and re-open at 4:30 eastern? As of late June 2021, this gap in time has been removed. The ES now trades between 4:15 and 4:30 continuously. I discovered a little bug in my code for this small gap when I was optimizing a “get out time.” I wanted to create a user function that uses the latest session start and end times and build a small database of valid times for the 24-hour markets. Close to 24 hours – most markets will close for an hour. With this small database you can test your time to see if it is a valid time. The construction of this database will require a little TIME math and require the use of arrays and loops. It is a good tutorial. However, it is not perfect. If you optimize time and you want to get out at 4:20 in 2020 on the ES, then you still run into the problem of this time not being valid. This requires a small workaround. Going forward with automated trading, this function might be useful. Most markets trade around the midnight hour – I think meats might be the exception.
Time Based Math
How many 5-minute bars are between 18:00 (prior day) and 17:00 (today)? We can do this in our heads 23 hours X (60 minutes / 5 minutes) or 23 X 12 = 276 bars. But we need to tell the computer how to do this and we also should allow users to use times that include minutes such as 18:55 to 14:25. Here’s the math – btw you may have a simpler approach.
Using startTime of 18:55 and endTime of 14:25.
Calculate the difference in hours and minutes from startTime to midnight and then in terms of minutes only.
timeDiffInHrsMins = 2360 – 1855 = 505 or 5 hours and 5 minutes. We use a little short cut hear. 23 hours and 60 minutes is the same as 2400 or midnight.
timeDiffInMinutes = intPortion(timeDiffInHrsMins/100) * 60 + mod(timeDiffInHrsMins,100). This looks much more complicated than it really is because we are using two helper functions – intPortion and mod:
) intPortion – returns the whole number from a fraction. If we divide 505/100 we get 5.05 and if we truncate the decimal we get 5 hours.
) mod – returns the modulus or remainder from a division operation. I use this function a lot. Mod(505/100) gives 5 minutes.
) Five hours * 60 minutes + Five minutes = 305 minutes.
Calculate the difference in hours and minutes from midnight to endTime and then in terms of minutes only.
timeDiffInHrsMins = endTime – 0 = 1425 or 14 hours and 25 minutes. We don’t need to use our little, short cut here since we are simply subtracting zero. I left the zero in the calculation to denote midnight.
timeDiffInMinutes = timeDiffInMinutes + intPortion(timeDiffInHrsMins/100) * 60 + mod(timeDiffInHrsMins,100). This is the same calculation as before, but we are adding the result to the number of minutes derived from the startTime to midnight.
) intPortion – returns the whole number from a fraction. If we divide 1425/100, we get 14.05 and if we truncate the decimal, we get 14.
) mod – returns the modulus or remainder from a division operation. I use this function a lot. Mod(1425/100) gives 25.
) 14* 60 + 25 = 865 minutes.
) Now add 305 minutes to 865. This gives us a total of 1165 minutes between the start and end times.
Now divide the timeDiffInMinutes by the barInterval. This gives 1165 minutes/5 minutes or 233 five-minute bars.
Build Database of all potential time stamps between start and end time
We now have all the ingredients to build are simple array-based database. Don’t let the word array scare you away. Follow the logic and you will see how easy it is to use them. First, we will create the database of all the time stamps between the regular session start and end times of the data on the chart. We will use the same time-based math (and a little more) to create this benchmark database. Check out the following code.
// You could use static arrays // reserve enough room for 24 hours of minute bars // 24 * 60 = 1440 // arrays: theoTimes[1440](0),validTimes[1440](0); // syntax - arrayName[size](0) - the zero sets all elements to zero // this seems like over kill because we don't know what // bar interval or time span the user will be using
// these arrays are dynamic // we dimension or reserve space for just what we need arrays: theoTimes[](0),validTimes[](0);
// Create a database of all times stamps that potentiall could // occur
// Now set the dimension of the array by using the following // function and the number of bars we calculated for the entire // regular session Array_setmaxindex(theoTimes,numBarsInCompleteSession); // Load the array from start time to end time // We know the start time and we know the number of X-min bars // loop from 1 to numBarsInCompleteSession and // use timeSum as the each and every time stamp // To get to the end of our journey we must use Time Based Math again. timeSum = startTime; for arrayIndex = 1 to numBarsInCompleteSession Begin timeSum = timeSum + barInterval; if mod(timeSum,100) = 60 Then timeSum = timeSum - 60 + 100; // 1860 - becomes 1900 if timeSum = 2400 Then timeSum = 0; // 2400 becomes 0000 theoTimes[arrayIndex] = timeSum;
print(d," theo time",arrayIndex," ",theoTimes[arrayIndex]); end;
Create a dynamic array with all possible time stamps
This is a simple looping mechanism that continually adds the barInterval to timeSum until numBarsInCompleteSession are exhausted. Reade about the difference between static and dynamic arrays in the code, please. Here’s how it works with a session start time of 1800:
theoTimes[01] = 1800 + 5 = 1805 theoTimes[02] = 1805 + 5 = 1810 theoTimes[04] = 1810 + 5 = 1815 theoTimes[05] = 1815 + 5 = 1820 theoTimes[06] = 1820 + 5 = 1830 ... //whoops - need more time based math 1860 is not valid theoTimes[12] = 1855 + 5 = 1860
Insert bar stamps into our theoTimes array
More time-based math
Our loop hit a snag when we came up with 1860 as a valid time. We all know that 1860 is really 1900. We need to intervene when this occurs. All we need to do is use our modulus function again to extract the minutes from our time.
If mod(timeSum,100) = 60 then timeSum = timeSum – 60 + 100. Her we remove the sixty minutes from the time and add an hour to it.
1860 – 60 + 100 = 1900 // a valid time stamp
That should fix everything right? What about this:
2400 is okay in Military Time but not in TradeStation
This is a simple fix with. All we need to do is check to see if timeSum = 2400 and if so, just simply reset to zero.
Build a database on our custom time frame.
Basically, do the same thing, but use the user’s choice of start and end times.
//calculate the number of barInterval bars in the //user defined session numBarsInSession = timeDiffInMinutes/barInterval;
Array_setmaxindex(validTimes,numBarsInSession);
startTimeStamp = calcTime(startTime,barInterval);
timeSum = startTime; for arrayIndex = 1 to numBarsInSession Begin timeSum = timeSum + barInterval; if mod(timeSum,100) = 60 Then timeSum = timeSum - 60 + 100; if timeSum = 2400 Then timeSum = 0; validTimes[arrayIndex] = timeSum; // print(d," valid times ",arrayIndex," ",validTimes[arrayIndex]," ",numBarsInSession); end;
Create another database using the time frame chose by the user
Don’t allow weird times!
Good programmers don’t allow extraneous values to bomb their functions. TRY and CATCH the erroneous input before proceeding. If we have a database of all possible time stamps, shouldn’t we use it to validate the user entry? Of course, we should.
//Are the users startTime and endTime valid //bar time stamps? Loop through all the times //and validate the times.
for arrayIndex = 1 to numBarsInCompleteSession begin if startTimeStamp = theoTimes[arrayIndex] then validStartTime = True; if endTime = theoTimes[arrayIndex] Then validEndTime = True; end;
Validate user's input.
Once we determine if both time inputs are valid, then we can determine if the any bar’s time stamp during a back-test is a valid time.
if validStartTime = false or validEndTime = false Then error = True;
//Okay to check for bar time stamps against our //database - only go through the loop until we //validate the time - break out when time is found //in database. CanTradeThisTime is the name of the function. //It returns either True or False
if error = False Then Begin for arrayIndex = 1 to numBarsInSession Begin if t = validTimes[arrayIndex] Then begin CanTradeThisTime = True; break; end; end; end;
This portion of the code is executed on every bar of the back-test.
Once and only Once!
The code that creates the theoretical and user defined time stamp database is only done on the very first bar of the chart. Also, the validation of the user’s input in only done once as well. This is accomplished by encasing this code inside a Once – begin – end.
Now this code will test any time stamp against the current regular session. If you run a test prior to June 2021, you will get a theoretical database that includes a 4:20, 4:25, and 4:30 on the ES futures. However, in actuality these bar stamps did not exist in the data. This might cause a problem when working with a start or end time prior to June 2021, that falls in this range.
Function Name: CanTradeThisTime
Complete code:
// Function to determine if time is in acceptable // set of times inputs: startTime(numericSimple),endTime(numericSimple);
if startTime <= endTime Then Begin timeDiffInHrsMins = (intPortion(endTime/100) - 1)*100 + mod(endTime,100) + 60 - startTime; timeDiffInMinutes = intPortion(timeDiffInHrsMins/100) * 60 + mod(timeDiffInHrsMins,100); end;
numBarsInSession = timeDiffInMinutes/barInterval;
Array_setmaxindex(validTimes,numBarsInSession);
startTimeStamp = calcTime(startTime,barInterval);
timeSum = startTime; for arrayIndex = 1 to numBarsInSession Begin timeSum = timeSum + barInterval; if mod(timeSum,100) = 60 Then timeSum = timeSum - 60 + 100; if timeSum = 2400 Then timeSum = 0; validTimes[arrayIndex] = timeSum; print(d," valid times ",arrayIndex," ",validTimes[arrayIndex]," ",numBarsInSession); end; for arrayIndex = 1 to numBarsInCompleteSession begin if startTimeStamp = theoTimes[arrayIndex] then validStartTime = True; if endTime = theoTimes[arrayIndex] Then validEndTime = True; end; end;
if validStartTime = False or validEndTime = false Then error = True;
if error = False Then Begin for arrayIndex = 1 to numBarsInSession Begin if t = validTimes[arrayIndex] Then begin CanTradeThisTime = True; break; end; end; end;
Complete CanTradeThisTime function code
Sandbox Strategy function driver
inputs: startTime(1800),endTime(1500);
if canTradeThisTime(startTime,endTime) Then if d = 1231206 or d = 1231207 then print(d," ",t," can trade this time");
I hope you find this useful. Remember to purchase by Easing into EasyLanguage books at amazon.com. The DayTrade edition is still on sale. Email me with any question or suggestions or bugs or anything else.
Easing Into EasyLanguage-DayTrade Edition [On SALE Now thru November]
EZ-DT Pyramania is a strategy I introduced in the Day Trade Edition. The logic is rather simple – pyramid as the market moves through multiple levels during the trading day. – buy, buy, buy, dump or buy, dump, short, short, short, dump. The distance between the levels is constant. In the book, I showed an algorithm with a total of 6 levels with 7 edges.
Here the market opens @ 9:30 and the levels are instantly plotted and trades are executed as the market moves through the levels located above the open tick. Over the weekend, I had a reader ask how he could modify the code to plot the levels on the 24-hour @ES session. In the day session, I used the change in the date as the trigger for the calculation and plotting of the levels. Here is the day session version.
inputs:numSegments(6),numPlots(6);
arrays: segmentBounds[](0);
variables: j(0),loopCnt(0),segmentSize(0),avgRng(0); once Begin Array_SetMaxIndex(segmentBounds, numSegments); end;
if d <> d[1] Then // only works on the @ES.D or any .D session begin avgRng = average(range of data2,20); segmentSize = avgRng/numSegments; loopCnt = -1*numSegments/2; for j = 0 to numSegments begin segmentBounds[j] = openD(0) + loopCnt * segmentSize; loopCnt = loopCnt + 1; end; end;
//The following time constraint only works when all time stamps //are less than the end of day time stamp //This will not work when time = 1800 and endTime = 1700 if t < calcTime(sessionEndTime(0,1),-barInterval) Then begin if numPlots >= 1 then plot1(segmentBounds[0],"Level 0"); if numPlots >= 2 then plot2(segmentBounds[1],"Level 1"); if numPlots >= 3 then plot3(segmentBounds[2],"Level 2"); if numPlots >= 4 then plot4(segmentBounds[3],"Level 3"); if numPlots >= 5 then plot5(segmentBounds[4],"Level 4"); if numPlots >= 6 then plot6(segmentBounds[5],"Level 5"); if numPlots >= 7 then plot7(segmentBounds[6],"Level 6"); // plot8(segmentBounds[7],"Level 7"); // plot9(segmentBounds[8],"Level 8"); end;
Works great with @ES.D or any @**.D
I like this code because it exposes you to arrays, loops, and plotting multiple values. You can fix this by modifying and adding some code. I used the Trading Around Midnight blog post to get the code I needed to enable plotting around 0:00 hours. Here is the updated code:
once Begin Array_SetMaxIndex(segmentBounds, numSegments); end;
startTime = sessionStartTime(0,1); endTime = sessionEndTime(0,1); //let TS tell you when the market opens - remember the //first time stamp is the open time + bar interval if t = calcTime(sessionStartTime(0,1),barInterval) Then begin avgRng = average(range of data2,20); segmentSize = avgRng/numSegments; loopCnt = -1*numSegments/2; for j = 0 to numSegments begin segmentBounds[j] = open + loopCnt * segmentSize; loopCnt = loopCnt + 1; end; end;
// if startTime > endTime then you know you are dealing with // timees that more than likely bridges midnight // if time is greater then 1700 (end time) then you must // subtract an offset so it makes sense - endTimeOffset // play with the math and it will come to you if startTime > endTime then begin endTimeOffset = 0; if t >= startTime+barInterval and t<= 2359 then endTimeOffSet = 2400-endTime; end; if t-endTimeOffSet < endTime Then begin if numPlots >= 1 then plot1(segmentBounds[0],"Level 0"); if numPlots >= 2 then plot2(segmentBounds[1],"Level 1"); if numPlots >= 3 then plot3(segmentBounds[2],"Level 2"); if numPlots >= 4 then plot4(segmentBounds[3],"Level 3"); if numPlots >= 5 then plot5(segmentBounds[4],"Level 4"); if numPlots >= 6 then plot6(segmentBounds[5],"Level 5"); if numPlots >= 7 then plot7(segmentBounds[6],"Level 6"); // plot8(segmentBounds[7],"Level 7"); // plot9(segmentBounds[8],"Level 8"); end;
Modification to plot data around midnight
Here I let TS tell me with the market opens and then use some simple math to make sure I can plot with the time is greater than and less than the end of day time.
Email me if you have the book and want to companion code to the strategy – georgeppruitt@gmail.com
Have You Ever Wondered If You Just Reversed the Logic?
You have been there before. What you thought was a great trading idea turns out to be a big flop. We have all developed these types of algorithms. Then it hits you, just flip the logic and in turn the equity curve. Hold your horses! First off you have to make sure it’s not just the execution costs that is hammering the equity curve into oblivion. When testing a fresh trading idea, it is best to keep execution costs to zero. This way if your idea is a good one, but is simply backward, then you have a chance of creating something good out of something bad. I was playing around with a mean reversion day trading algorithm (on the @ES.D – day session of the mini S&P 500) that created the following equity curve. Remember to read the disclaimer concerning hypothetical performance before proceeding reading the rest of this blog. It is located under the DISCLAIMER – REAMDE! tab. By reading the rest of this blog post it implies that you understand the limitations of hypothetical back testing and simulated analysis.
The pandemic created a strong mean reversion environment. In the initial stage of this research, I did not set the executions costs – they defaulted to zero. My idea was to buy below the open after the market moved down from the high of the day a certain percentage of price. Since I was going to be buying as the market was moving down, I was willing to use a wide stop to see if I could hold on to the falling knife. Short entries were just the opposite -sell short above the open after the market rallied a certain percentage of price. I wanted to enter on a hiccup. Once the market moved down a certain range from the high of the day, I wanted to enter on a stop at the high of the prior bar. I figured if the price penetrated the high of the prior five-minute bar in a down move, then it would signal an eventual rotation in the market. Again, I was just throwing pasta against the wall to see what would stick. I even came up with a really neat name for the algorithm the Rubber Band system – stretch just far enough and the market is bound to slam back. Well, there wasn’t any pasta sticking. Or was there? If I flipped the equity curve 180 degrees, then I would have a darned good strategy. All it would take is to reverse the signals, sell short when I was buying and buy when I was selling short. Instead of a mean reversion scheme, this would turn into a momentum-based strategy.
if c < todaysOpen and todaysOpen-c = maxOpenMinusClose and (maxCloseMinusOpen + maxOpenMinusClose)/c >= stretchPercent Then canBuy = True; if c > todaysOpen and c- todaysOpen = maxCloseMinusOpen and (maxCloseMinusOpen + maxOpenMinusClose)/c >= stretchPercent Then canShort = True;
Guts of the complete failure.
Here I measure the maximum distance from the highest close above the open and the lowest close below the open. The distance between the two points is the range between the highest and lowest closing price of the current day. If the close is less than today’s open, and the range between the extremes of the highest close and lowest close of the trading day is greater than stretchPercent, then an order directive to buy the next bar at the current bar’s high is issued. The order is alive until it is filled, or the day expires. Selling short uses the same calculations but requires the close of the current bar to be above the open. The stretchPercent was set to 1 percent and the protective stop was set to a wide $2,000. As you can see from the equity curve, this plan did not work except for the time span of the pandemic. Could you optimize the strategy and make it a winning system. Definitely. But the 1 percent and $2000 stop seemed very logical to me. Since we are comparing the range of the data to a fixed price of the data, then we don’t need to worry about the continuous contract distortion. Maybe we would have to, if the market price was straddling zero. Anyways, here is a strategy using the same entry technique, but reversed, with some intelligent trade filtering. I figured a profit objective might be beneficial, because the stop was hit several times during the original test.
If you like the following code, make sure you check out my books at Amazon.com. This type of code is used the Hi-Res and Day-Trading editions of the Easing_Into_Easylanguage series.
if c < todaysOpen and todaysOpen-c = maxOpenMinusClose and (maxCloseMinusOpen + maxOpenMinusClose)/c >= stretchPercent Then canShort = True; if c > todaysOpen and c- todaysOpen = maxCloseMinusOpen and (maxCloseMinusOpen + maxOpenMinusClose)/c >= stretchPercent Then canBuy = True;
if canTrade and t >= calcTime(dontTradeBefore,dontTradeBeforeOffset) and t < calcTime(dontTradeAfter,dontTradeAfterOffset) and t < sessionEndTime(0,1) Then begin if shortsToday = 0 and canShort = True Then sellshort next bar at l stop; if buysToday = 0 and canBuy = True Then buy next bar at h stop; end;
Trade filtering was obtained by limiting the duration during the trading day that a trade could take place. It’s usually wise to wait a few minutes after the open and a few minutes prior to the close to issue trade directives. Also, range compression of the prior day seems to help in many cases. Or at least not range expansion. I only allow one long entry or one short or both during the trading day – two entries only! Read the code and let me know if you have any questions. This is a good framework for other areas of research. Limiting entries using the mp variable is a neat technique that you can use elsewhere.
And as always let me know if you see any bugs in the code. Like Donnie Knuth says, “Beware of bugs in the above code; I have only proved it correct, not tried it!”
Backtesting with [Trade Station,Python,AmiBroker, Excel]. Intended for informational and educational purposes only!
Get All Five Books in the Easing Into EasyLanguage Series - The Trend Following Edition is now Available!
Announcement – A Trend Following edition has been added to my Easing into EasyLanguage Series! This edition will be the fifth and final installment and will utilize concepts discussed in the Foundation editions. I will pay respect to the legends of Trend Following by replicating the essence of their algorithms. Learn about the most prominent form of algorithmic trading. But get geared up for it by reading the first four editions in the series now. Get your favorite QUANT the books they need!
This series includes five editions that covers the full spectrum of the EasyLanguage programming language. Fully compliant with TradeStation and mostly compliant with MultiCharts. Start out with the Foundation Edition. It is designed for the new user of EasyLanguage or for those you would like to have a refresher course. There are 13 tutorials ranging from creating Strategies to PaintBars. Learn how to create your own functions or apply stops and profit objectives. Ever wanted to know how to find an inside day that is also a Narrow Range 7 (NR7?) Now you can, and the best part is you get over 4 HOURS OF VIDEO INSTRUCTION – one for each tutorial.
This book is ideal for those who have completed the Foundation Edition or have some experience with EasyLanguage, especially if you’re ready to take your programming skills to the next level. The Hi-Res Edition is designed for programmers who want to build intraday trading systems, incorporating trade management techniques like profit targets and stop losses. This edition bridges the gap between daily and intraday bar programming, making it easier to handle challenges like tracking the sequence of high and low prices within the trading day. Plus, enjoy 5 hours of video instruction to guide you through each tutorial.
The Advanced Topics Edition delves into essential programming concepts within EasyLanguage, offering a focused approach to complex topics. This book covers arrays and fixed-length buffers, including methods for element management, extraction, and sorting. Explore finite state machines using the switch-case construct, text graphic manipulation to retrieve precise X and Y coordinates, and gain insights into seasonality with the Ruggiero/Barna Universal Seasonal and Sheldon Knight Seasonal methods. Additionally, learn to build EasyLanguage projects, integrate fundamental data like Commitment of Traders, and create multi-timeframe indicators for comprehensive analysis.
The Day Trading Edition complements the other books in the series, diving into the popular approach of day trading, where overnight risk is avoided (though daytime risk still applies!). Programming on high-resolution data, such as five- or one-minute bars, can be challenging, and this book provides guidance without claiming to be a “Holy Grail.” It’s not for ultra-high-frequency trading but rather for those interested in techniques like volatility-based breakouts, pyramiding, scaling out, and zone-based trading. Ideal for readers of the Foundation and Hi-Res editions or those with EasyLanguage experience, this book offers insights into algorithms that shaped the day trading industry.
For thirty-one years as the Director of Research at Futures Truth Magazine, I had the privilege of collaborating with renowned experts in technical analysis, including Fitschen, Stuckey, Ruggiero, Fox, and Waite. I gained invaluable insights as I watched their trend-following methods reach impressive peaks, face sharp declines, and ultimately rebound. From late 2014 to early 2020, I witnessed a dramatic downturn across the trend-following industry. Iconic systems like Aberration, CatScan, Andromeda, and Super Turtle—once thriving on robust trends of the 1990s through early 2010s—began to falter long before the pandemic. Since 2020 we have seen the familiar trends return. Get six hours of video instruction with this edition.
Pick up your copies today – e-Book or paperback format – at Amazon.com