Day Of Week Analysis using a Method In EasyLanguage

One metric that seems to be missing from TradeStation is a Day Of Week analysis.  It would be nice, but I don’t know how helpful, to know the $P/L breakdown on a weekday basis; does your system make all of its money on Mondays and Fridays?  I created the code that will print out to the print log using an EasyLanguage method.  A method is a subroutine that can be included in the main code (strategy, indicator, etc.,.)  The global parameters to the main program can be seen inside the method.  You can localize variable scope to the method by declaring the variable within the method’s body.  A method is a great way to modularize your programming, but it is not the best way to reuse software; the method is accessible only to the main program.  This EasyLanguage also utilizes an array and shows a neat piece of code to access the array elements and align them with the day of the week.  The dayOfWeek() function returns [1..5] depending on what day of the week the trading day falls on.  Monday = 1 and Friday = 5.  The array has five elements and each element accumulates the $P/L for each of the five days based on when the trade was initiated.

vars: mp(0);
array: weekArray[5](0);

method void dayOfWeekAnalysis()   {method definition}
var: double tradeProfit;
begin
	If mp = 1 and mp[1] = -1 then tradeProfit = (entryPrice(1) - entryPrice(0))*bigPointValue;
	If mp = -1 and mp[1] = 1 then tradeProfit = (entryPrice(0) - entryPrice(1))*bigPointValue;
	weekArray[dayOfWeek(entryDate(1))] = weekArray[dayOfWeek(entryDate(1))] + tradeProfit;
end; 
Buy next bar at highest(high,9)[1] stop;
Sellshort next bar at lowest(low,9)[1] stop;

mp = marketPosition;

if mp <> mp[1] then dayOfWeekAnalysis();

If lastBarOnChart then
Begin
	print("Monday ",weekArray[1]);
	print("Tuesday ",weekArray[2]);
	print("Wednesday ",weekArray[3]);
	print("Thursday ",weekArray[4]);
	print("Friday ",weekArray[5]);
end;
Code using METHOD and ARRAY manipulation

Here is an example of the print out created by running this simple EasyLanguage strategy.  Maybe don’t trade on Monday?  Or is that curve fitting.  This is an interesting tool and might carry more weight if applied to day trade algorithm.  Maybe!

  • Monday -8612.50
  • Tuesday 6350.00
  • Wednesday 2612.50
  • Thursday -937.50
  • Friday -1987.50

Connors and Raschke (Momentum Pinball)™ EasyLanguage

In the Connors Raschke book, “Street Smarts – High Probability Short-Term Trading Strategies” published by M. Gordon Publishing Group 1995, the authors describe a strategy that incorporates several ideas and functions that can be difficult to program into TradeStation.  I highly suggest purchasing the book as it has some very interesting ideas and comes from the minds of two very accomplished traders.

The strategy is conceptually simple and uses the Taylor Buy/Sell day concept.   On buy days, buy on the penetration of the first hour high and use the extreme of the first hour as the stop.  If you get stopped out the system will allow you to re-enter once more on a re-penetration of the first hour high.  If the trade is profitable at the close of the day session then exit on the open of the following day.  Selling short is just the opposite.  The Buy Day is defined when the three day RSI of the one day ROC (close[0] – close[1]) is below 30 and the Sell Day  is defined when this indicator rises above 70.  As you can see, pretty simply.

The first problem when programming this strategy is the mixing of the 5 minute bars (for trade execution) and daily bars (calculating the indicator.)  How do you calculate an RSI(c[0] – c[1],3) indicator value when looking at a 5 minute bar chart.   This turns out to be pretty simple since TradeStation allows the mixing of different time frames on the same chart.  First plot a 5 minute bar of the @ES.D as data 1 and then insert a daily bar of the @ES.D as data 2.   The first step in programming this strategy is setting up the indicator.

//EasyLanguage

Vars: rsiVal(0,data2);

rsiVal = rsi(close of data2 - close[1] of data2,3);
Setting up the nested indicator.

Notice how I declared the variable rsiVal?  I initially set it to zero and tie it to data2.  This tying or aliasing limits the variable from being updated on each five minute bar.  Remember we want the RSI calculation done on the daily bars.  The RSI function allows the embedding of calculations as well as different prices.  Here we are telling the computer to look at the momentum of today’s close versus yesterday’s  and apply the RSI  3 – period calculation.

In their book Connors and Raschke determined that it would be better to buy after an RSI reading of below 30 and sell after an RSI above 70.  Once we have this set, then the fun really begins with this type of programming.  If you can do this type of programming, there’s very little you can’t do.  This is because we are solving a few limitations of EasyLanguage by logically addressing the what we need from language. In this example, we have to capture the range of the first hour.  There really isn’t a built-in way to do this or at least not an easy one.  When testing intra-day, I always like using five minute bars.  This time frame is small enough that not much usually happens during this t time and it isn’t much of a resource hog – like say minute or smaller bars. Since there are 12 five minute bars in an hour, I wait until the 12th bar of the day is completed to determine the first hour’s range and its extremes.  I set the dayBarCount to zero on the first bar of the day and then increment the variable on each bar.

If date <> date[1] then
begin
	dayBarCount = 0;
	buysToday = 0;
	sellsToday = 0;
end;

dayBarCount = dayBarCount + 1;

If dayBarCount = 12 then
Begin
	buyLevel = highD(0) + minMove/priceScale;
	sellLevel = lowD(0) - minMove/priceScale;
end;
Tracking the number of bars and capturing first hour.

TradeStation has made this process simpler by providing the highD and lowD functions.  When you call these functions the current daily bar extremes are returned at the point in the day.  So the functions are called on the 12th bar and they return the high and low of the first hour.   The functions are not called again until the next day.  Oh yeah – passing a zero as the function argument informs EasyLanguage to return today’s values.  A 1 would return yesterday’s values.  These are nifty functions if you aren’t incorporating a secondary daily data stream.  Even if you are, like in our example, they still come in handy.

mp = marketPosition;

If mp = 1 and mp[1] <> 1 then buysToday = buysToday + 1;
If mp = -1 and mp[1] <> -1 then sellsToday = sellsToday + 1;

If dayBarCount > 12 and time < 1430 then
Begin
	if rsiVal < 30 and mp <> 1 and buysToday < 2 then buy next bar at buyLevel Stop;
	If rsiVal > 70 and mp <> -1 and sellsToday < 2 then sellShort next bar at sellLevel stop;
end;
Order placement directives and the use of mp.

I also keep track of the number of buys and shorts for the day.  The books states that a re-entry is possible, so I allow up to two trade entries.  I look and the current MP value and its prior value to see if  the system went from one state to another.  If current MP is long and the prior reading is not long, then a long entry was undoubtedly entered.  You can use this logic (I did for illustrative purposes) or use the built-in functions entriesShortToday/entriesLongToday to determine the number of trades for the day.  If the rsiValue < 30 and less than two long entries have occurred, then you can buy on a breakout of the first hourly bar.  Entering short is the opposite, but with the RSI reading of greater than 70.

If mp = 1 then
Begin
	Sell next bar at sellLevel stop;
end;

If mp= -1 then
Begin
	Buytocover next bar at buyLevel stop;
end;

If time = 1510 and openPositionProfit < 0 then setExitOnClose;
If time = 1515 then
Begin
	If mp = 1 then sell next bar at open;
	If mp =-1 then buyToCover next bar at open;
end;
Initial stop and if winning trade exit next morning else get out on close.

The buy/sell levels are the first hourly bar’s extreme +/- min. tick.  These levels are used as protective stops as well as entry levels.  If long then the first hourly bar’s low is the protective stop.  Notice how I check at 1510 if the trade is in a profit by examining the current openPositionProfit.  I am checking five minutes prior to the close because I need to execute setExitOnClose if in a loss.  I don’t think I can check at 15:15 (closing time) and then exit, but I will check and let you know.

The last little trick is to execute on the open tick the next morning.  I have explained in my books the different trading paradigms where you are either sitting on the prior bar when you place orders or sitting on the open of the current bar.  EasyLanguage assumes the former so you always have to place an order for the next bar.  If you wait until the open, then the earliest you can exit is 8:35.  So you have to issue the order on the last bar of the prior day to get the open tick, hence the test to see if the time stamp is 15:15.

This sample of EasyLanguage is a good example of some easy fixes to things that usually leave beginning EasyLanguage coders scratching their heads and groaning out loud.

Trade Entry/Exit Functions in PSB

Since Python doesn’t  allow for a GOTO program flow structure I changed the inline trade entry/exit logic into function calls.  This allows for the call of these functions to be non-sequential.  The original PSB order placement was sequential and would examine the entry/exit logic in TOP-DOWN fashion.  Meaning that if you put the Long Entry Logic first, the program would evaluate that logic first on every bar of data.  This was fine for the majority of trading systems out there.  However, systems that could enter multiple signals on the same bar require the orders to be placed in order of whichever was closest to the current market price.  Let’s say you have a trading algorithm that issues a stop to exit at a loss and a stop to reverse your current position.  If you examine the reversal logic prior to the stop loss and the stop loss is actually closer, then you will execute the wrong signal first.   By encapsulating the entry/exit logic into functions you can use decision constructs to flow through the correct logic in the correct order.  Here are the trade signals programmed as function calls:

entryexitfuncs

As you can see there are six modules – Long Entry, Long Loss, Long Profit, Short Entry, Short Loss, and Short Profit (note non-necessary code was collapsed).  I used the Sublime text editor to collapse the unnecessary lines of code.  You can download a trail version from their website.  I am no longer using the IDLE as my go to IDE – I have fallen deeply in love with PyScripter.  I will delve into this subject later.

Now that you have all your trade signals programmed as functions you can utilize if-thens to determine what order they are called.  Here is the code that calls these functions

functionflow

If you are flat and you can buy or sell on the same day then you call both functions.  This back tester will allow you to buy and sell on the same day – the only problem is it doesn’t know which occurred first: the buy or the sell.  This can cause a problem because you need to know the correct position by the end of the day.  Since we can peak into the future (be very, very careful) we can look at the close of the day and compare it with the long and short entry prices.  Here is some code that might make your entries more accurate on those occasions where both orders could be filled.

if myHigh[D0] >= buyLevel and myLow[D0] <= sellLevel:
	closeToBuyDiff = myClose[D0] -  buyLevel
	closeToSellDiff = sellLevel - myClose[D0]
    	if closeToBuyDiff < closeToSellDiff:
    		se = sellEntry(sellLevel)
	    	le = longEntry(buyLevel)
      	else:
    		le = longEntry(buyLevel)
    		se = sellEntry(sellLevel)
					
Increasing Trade Entry/Exit Accuracy - Maybe?

This code will execute the long entry logic after the short entry logic whenever the close is closer to the long entry price than the short entry price.  If both orders are filled on the same bar and the close happens to fall closer to the long entry price, then the software assumes the short entry was entered earlier in the day and the long entry later in the day making the position at end of day long.  Is this 100% accurate?  No but it logically stands to reason that a close near the high would indicate they high was made last.  Without intraday data we simply do not know what happened first.

Using Jupyter Notebook and Plot.ly To Create Candle Stick Chart

In today’s post I show how you can plot a very nice looking Candlestick chart inside a Jupyter (IPython) notebook. This chore is
made much easier by using  Plotly. So first thing you sholud do is sign up for a free account at Plotly and then download Jupyter Interactive Python notebooks.  I did this in an interactive notebook for demonstration purposes only.  After installing Plotly I was able to import the libraries into my notebook and then call the various functions to graph the data.  I imported numpy, but it wasn’t necessary.  I simply copied some data (CL.CSV) to the subdirectory that held my notebooks and then used the CSV Reader to pull the data into the various lists that the Plotly functions required.  All of the plotting is done in a browser and its interactive.  After creating the PSB I wanted to provide a tool for plotting the data that was being tested.  Jupyter and Plotly are free for non-commercial users.

import numpy as np
import datetime
import csv
import plotly.plotly as py
from plotly.tools import FigureFactory as FF
from plotly.graph_objs import *

d = list()
dt = list()
o = list()
h = list()
l = list()
c = list()
v = list()
oi = list()
cnt = 0

with open("CL.CSV") as f:
    f_csv = csv.reader(f)
    for row in f_csv:
        numCols = len(row)
        cnt += 1
        d.append(int(row[0]))
        dt.append(datetime.datetime.strptime(row[0],'%Y%m%d'))
        o.append(float(row[1]))
        h.append(float(row[2]))
        l.append(float(row[3]))
        c.append(float(row[4]))
        v.append(float(row[5]))
        oi.append(float(row[6]))
        
xDate = list()
yVal = list()
indicCnt = 0
for i in range(len(c)-40,len(c)):
    xDate.append(dt[i])
    sum = 0.0
    for j in range(i-9,i):
        sum += c[j]
    yVal.append(sum/10)
                      
fig = FF.create_candlestick(o, h,l, c, dt)

add_line = Scatter(
    x=xDate, 
    y=yVal, 
    name= 'movingAverage', 
    line=Line(color='blue')
    )

fig['data'].extend([add_line])

py.iplot(fig, filename='simple-candlestick', validate=False)
Candlesticks with Plot.ly
CandleStick of Crude Oil with Moving Average Overlay
CandleStick of Crude Oil with Moving Average Overlay

Restructuring Trade Entry with PSB

It has been brought to my attention by a very astute reader of the book that the ordering of the buy/sell/longliq/shortliq directives creates a potential error by giving preference to entries.  The code in the book and my examples thus far test for a true condition first in the entry logic and then in the exit logic.  Let’s say your long exit stop in the Euros is set at 11020, but your reversal is set at 11000.  The python back tester will skip the exit at 11020 and reverse at 11000.  This only happens if both stops are hit on the same day.  If this happens you will incur a 20 point additional loss.  You can prevent this by using logic similar to:

if ((mp == 0 or (mp == -1 and stb < stopb)) and myHigh[D0] >= stb) :
Eliminate Reversal Bias

Notice bow I compare the price level of stb and stopb [stb – reversal and stopb – liquidation].  I added this to the long entry logic – the code is only executed if the entry is less than the exit (closer to the current market).  I am in the process of restructuring the flow so that all orders will be examined on a bar by bar basis and the ones that should take place (chronologically speaking) will do so and be reflected in the performance metrics.  This can cause multiple trades on a single bar.  This is what happens in real trading and should be reflected in the PSB.  This is where the lack of a GOTO creates a small headache in Python.  The ESB already takes this into consieration.  I will post when I finalize the code.

Version 2.0 of Python System Back-tester Available

I have just wrapped up the latest version of the Python System Back-tester (PSB).

I have added some more portfolio performance metrics and you will see these in the performance reports.  The most useful addition is the concept of the .POR file when you run a system.  Instead of having to select your data files each time you run a system, you can build a .POR file with a list of files/markets you want to batch run.

Here is an example of a Portfolio file:

TY.CSV

CU.CSV

SB.CSV

S2.CSV

QG.CSV

QM.CSV

C2.CSV

Just make sure you put the .POR file inside the same folder that contains your testing data.  I have included a TestPortfolio.por file in version 2.0.  I would treat the different versions as completely separate applications.  Your existing .py algorithm files will need to be slightly modified to work with version 2.0.

This line of code needs to be modified from this:

systemMarket.setSysMarkInfo(sysName,myComName,listOfTrades,equity)

to this:

systemMarket.setSysMarkInfo(sysName,myComName,listOfTrades,equity,initCapital)

This line is near the bottom of the overall loop.  I added the initCapital variable so you could do position sizing and the performance metrics would reflect this initial value.

And set initCapital to a pertinent value.  I put it right below the sysName variable:

sysName = ‘BollingerBandSys’ #System Name here

initCapital = 100000 #starting account balance

Also I corrected a small bug in the main loop.  You should change this:

for i in range(len(myDate) – numBarsToGoBack,len(myDate)):

to

for i in range(len(myDate) – (numBarsToGoBack-rampUp),len(myDate)):

In another post I will show how the portfolio performance metrics have changed.  I hope you like the new version.  I will be adding a library of trading systems utilizing this new version in a few days.

If you want to download Version 2.0 – just go the the following link

PSBVersion2.0

If You Can Do This – You Can Test Any Algorithm!

All the unnecessary lines of the Python System Back-Testing Module have been hidden.  Only the lines that you need to develop the next great algorithm are included.  Reads sort  of like English.  This snippet introduces you to the use of functions and lists – two major components of the Python language.  If you buy my latest book – “The Ultimate Algorithmic Trading System Toolbox” then simply email me or sign up through the contact form and you will get version 2.0 for free!

PythonReduction

Macintosh version of Excel System Back-Tester Available

It was recently brought to my attention that the Excel System Back-Tester(ESB) did not function properly on the MAC OS X.  In other words it bombed when trying to open a comma delimited data file and also when one tried to run an algorithm.  Thanks to a purchaser of the UATSTB I was able to fix the bugs without removing any functionality.  I will post the Macintosh version here as well as have WILEY put it on the book’s website.  Sorry for any inconvenience this may have caused.  Here is the the link:

 

ESB Macintosh

Turtle Volatility Loss in Python Back Tester – Part 3 in Series

The Turtle N or Volatility is basically a 20-day Average True Range in terms of  Dollars.  This amount is considered the market volatility.  In other words the market, based on the average, can either move up or down by this amount.  It can move much less or much further; this is just an estimate.  If the market moves 2 N against a position, then as a Turtle you were to liquidate your stake in that commodity.  The logic indicates that if the market has a break out and then moves 2 N in the opposite direction, then the break out has failed.  First the code must be defined to represent the market volatility.  This is simple enough by using the sAverage function call and passing it the trueRanges and 20 days.  There’s no use in converting this to dollars because what we want is a price offset.  Once a position is entered the turtleN  is either added to the price [short position] or subtracted from the price [long position] to determine the respective stop levels.  Look at lines 2, 8 and 17 to see how this is handled.  An additional  trade code block must be added to facilitate this stop.  Lines 17 to 28 takes care of exiting a long position when the market moves 2 N in the opposite direction.   This new stop is in addition to the highest/lowest high/low stops for the past 10 -20 days.

        atrVal = sAverage(trueRanges,20,i,1)
        turtleN = atrVal*2


            if lastTradeLoser == True :
                tradeName = "Turt20Buy"
                mp += 1
                longNExitStop = price - turtleN
                marketPosition[i] = mp
                entryPrice.append(price)
                entryQuant.append(numShares)
                curShares = curShares + numShares
                trades = tradeInfo('buy',myDate[i],tradeName,entryPrice[-1],numShares,1)
                barsSinceEntry = 1
                listOfTrades.append(trades)
#long Exit - 2 N Loss
        if mp >= 1 and myLow[i] <= longNExitStop and barsSinceEntry > 1:
            price = min(myOpen[i],longNExitStop)
            tradeName = "LongNExitLoss"
            exitDate =myDate[i]
            numShares = curShares
            exitQuant.append(numShares)
            profit,trades,curShares = exitPos(price,myDate[i],tradeName,numShares)
            if curShares == 0 : mp = marketPosition[i] = 0
            totProfit += profit
            todaysCTE = profit
            listOfTrades.append(trades)
            maxPositionL = maxPositionL - 1
Turtle Part 3

 

Turtle (Last Trade Was A Loser (LTL)) Filter – Part 2 in Series

How many of you believe if the last trade was a winner, the probability of the next trade being a loser is higher? The Turtles believed this and in this post I introduce the concept of filtering trades based on the prior trade’s success.

Here is a list of trades without the filter:


20090506    Turt20Buy  1  91.75000       0.00       0.00
20090622   Long10-Liq  1 103.14000   11290.00   11290.00
20090702   Turt20Shrt  1 102.26000       0.00       0.00
20090721   Shrt10-Liq  1 100.80000    1360.00   12650.00
20090803    Turt20Buy  1 104.61000       0.00       0.00
20090817   Long10-Liq  1 101.99000   -2720.00    9930.00
20090824    Turt20Buy  1 107.71000       0.00       0.00
20090902   Long10-Liq  1 100.97000   -6840.00    3090.00
20090902   Turt20Shrt  1 100.10000       0.00       0.00
20090917   Shrt10-Liq  1 105.87000   -5870.00   -2780.00
20090924   Turt20Shrt  1 100.02000       0.00       0.00
20091008   Shrt10-Liq  1 104.72000   -4800.00   -7580.00
20091012    Turt20Buy  1 106.13000       0.00       0.00
20091030   Long10-Liq  1 109.43000    3200.00   -4380.00
20091113   Turt20Shrt  1 108.95000       0.00       0.00
20091223   Shrt10-Liq  1 106.03000    2820.00   -1560.00

And here are the trades with filter engaged:


20090506    Turt20Buy  1  91.75000       0.00       0.00
20090622   Long10-Liq  1 103.14000   11290.00   11290.00
20090824    Turt20Buy  1 107.71000       0.00       0.00
20090902   Long10-Liq  1 100.97000   -6840.00    4450.00
20090902   Turt20Shrt  1 100.10000       0.00       0.00
20090917   Shrt10-Liq  1 105.87000   -5870.00   -1420.00
20090924   Turt20Shrt  1 100.02000       0.00       0.00
20091008   Shrt10-Liq  1 104.72000   -4800.00   -6220.00
20091012    Turt20Buy  1 106.13000       0.00       0.00
20091030   Long10-Liq  1 109.43000    3200.00   -3020.00
20100126   Turt20Shrt  1 104.09000       0.00       0.00
20100218   Shrt10-Liq  1 108.12000   -4130.00   -7150.00
20100219    Turt20Buy  1 109.37000       0.00       0.00
20100322   Long10-Liq  1 108.96000    -510.00   -7660.00

Check for yourself – you will notice that a trade after a winner is skipped. Trades are not picked back up until a loser is reported. Trading like this is quite easy but backtesting is quite a bit more difficult. I talk about this in the book where you have to switch between actual trading and simulated trading. The beauty of the Python BackTester is that it is somewhat easy to incorporate this into the testing logic. All you have to do is determine if the prior real or simulated trade is a loser. If it isn’t then you still must keep track of all trades, but don’t book the trades that follow the winner. I have created a testing module that does just that. Here is a snippet of the code:

# Short Logic
        if (mp == 0 or mp == 1) and barsSinceEntry > 1 and myLow[i] <= ll20: profit = 0 price = min(myOpen[i],ll20) numShares = max(1,int(dollarRiskPerTrade/(atrVal*myBPV))) if mp >= 1:
            profit,trades,curShares=exitPos(price,myDate[i],"RevLongLiq",curShares,lastTradeLoser)
                if lastTradeLoser < 1 : listOfTrades.append(trades) todaysCTE = profit if profit > 0 :
                    if lastTradeLoser < 0 : lastTradeLoser = 0 if lastTradeLoser > 0 : lastTradeLoser +=1
                else:
                    lastTradeLoser = -1
                mp = 0
            mp -= 1
            tradeName = "Turt20Shrt"
            marketPosition[i] = mp
            entryPrice.append(price)
            entryQuant.append(numShares)
            curShares = curShares + numShares
            trades = tradeInfo('sell',myDate[i],tradeName,entryPrice[-1],numShares,1)
            barsSinceEntry = 1
            if lastTradeLoser < 1:
               listOfTrades.append(trades) <strong># book the trade if lastTradeLoser < 1 else don't</strong>
               totProfit += profit         <strong># book the profit from the trade</strong>
Turtle Part 1

I will include this in an update to the Python backtester for registered users of this site.

Backtesting with [Trade Station,Python,AmiBroker, Excel]

Follow

Get every new post delivered to your Inbox

Join other followers: