© Ed Seykota, 2003 - 2005 ... Write for permission to reprint.

Ed Seykota's

Frequently Asked Questions

FAQ Index & Ground Rules  ...  Tribe Directory - How to Join

TTP - The Trading Tribe Process  ...  Glossary

  TTP Workshop  ...  Resources  ...  The Trading Tribe Book

Sat, 22 Oct 2005

(n+1)/2  and  DT

Dear Mr. Seykota,

Using your data, SP----C-1.csv :

And equation:
ELt = ELt-1 + dt * (P - ELt-1) / TC

Where,
t       = Aug 22, 1982
t-1    = Aug 21, 1982
ELt-1 = 117.45
dt     = 1
P      = 117.90
TC    = 150

ELt   = 117.453

on your website it shows: http://www.seykota.com/tribe/TSP/EA/2005_u_11_EA_System/Metrics_Log_0-0.txt
 

ELt   = 117.456

See the TSP resources for more information of the theory of lags and moving averages and the (n+1)/2 factor.

Yes, this particular system increments the lags on trading days only.  If you include increments for holidays and weekends, you get slightly different values for the lags and, perhaps, slightly different trading results.  You might even get a different optimal solution.  You might then use that optimal to run the every-day-incremental system.

Mon, 24 Oct 2005

TSP Exponential Lag Match - To The Penny

I match your run to the penny and narrowed the search using your results as a starting point.

Slow Lag= 325
Fast Lag= 85
Bliss = 0.210
ICAGR = 0.112
Drawdown = -0.534
start bal = $1,000,000.00
end bal = $13,551,818.75
 

Very nice !

Tue, 18 Oct 2005
 

Match

Hi, Ed -- using Excel, I have matched the ending equity for the 150/15 system to the penny, and also have matched the ICAGR -- your number .0514, mine .05139703, which is close enough for government work!

For more information on draw down, see resources / system math.  The Trade Log and the Metrics Log are different views of the results, I do not generate one from the other.

Mon, 17 Oct 2005

See Below.

Mon, 17 Oct 2005

Animated GIF for bliss;

Reproding Results for Exponential Crossover System


Dear Ed,

I reproduced the results for the "Exponential Crossover System" for both parameter sets (150/15) and (325/85) to the penny. I am using my own backtesting engine written in C#. I had to change the type of some variables of my backtesting engine from float (4 byte) to double (8 byte).

I created an animated GIF for the "Exponential Crossover System". The GIF contains a graphic showing how bliss depends on the "Slow Averaging Time", the "Fast Averaging Time" and the "Heat". I simply generated different frames for different values of heat, so the heat changes with the time as the animation runs. You can open the GIFs in a web browser or other software which is capable of playing animated GIFs.

I also wanted to make you aware of what I believe is a mistake. You write that the start equity is 100000000.00 instead of 1000000.00 in the tables on following pages:

http://www.seykota.com/tribe/TSP/EA/2005_u_11_EA_System/0-0.htm
http://www.seykota.com/tribe/TSP/EA/2005_u_11_EA_System/7-7.htm

Greetings!

Nice Graphics !  For you other comments, see below.

Mon, 17 Oct 2005

The 100x factor stems from comparing pennies and dollars.  For information on contract sizing, See below.

Sun, 16 Oct 2005

Skid Problems

Ed,

I am not able to get Skid working in the commercial software packages. Is there anyone out there that has matched your 150-15 EMA Cross Over system in TradersStudio, TradeStation, MetaStock, or some other commercial software package?

I was working on the EMA Cross Over system today and have an Excel model working that matches your 150-15 system, but am still not able to match the system in TradersStudio or TradeStation or MetaStock. I was able to get around the initialization differences for the EMA because of MaxBarsBack requirements in the commercial software, and was able to match the EMA and ATR by writing custom functions, but I am not able to get around the SkidPrice calculation as of yet.

In the commercial software when an order is triggered, they can access Open and High for that day, but they are not able to access the Open and High for the next day when the order actually fills. So, I can't get the SkidPrice to match by one day.

Skid is defined as 50% of the distance between the Open and the High the day the limit order fills.

The TradersStudio code that is not working is:

Skid = 0.5
If CrossesOver(FastEMA,SlowEMA) Then
SkidPrice = Open[0]+(Skid*(High[0]-Open[0]))
Buy("Buy",PositionSize,SkidPrice,Limit,Day)
End If

In the code above, the entry price (SkidPrice) is calculated on the range between Open and High on the day the Buy signal is triggered, not on the day the order is actually filled in the market the next day.

Theoretically the following code would access tomorrows SkidPrice:

I do not know of commercial testers that allow you to access anything about tomorrow, today.

Sun, 16 Oct 2005

The system accounting uses lots that have a value of $1.00 / per handle and rounds to the nearest 50, which is one mini contract.  In this case 6,500 lots equals 130 contracts that have a gearing of $50.00 / handle.  The current margin on the mini is about $4,000 so the total margin requirement is about $520,000.

The risk per trade is not the same thing as the margin per trade.

Tue, 13 Sep 2005

For a real thrill, you might try swimming Lake Tahoe in the winter.

Tue, 13 Sep 2005

Still Finding Differences:

Seeking the limit as epsilon goes to zero

Ed,

When I format my log files exactly as yours are formatted and use the Unix diff command on them I notice some small differences in the metrics log. The other 2 logs are identical.

1) you have 2 entries for 05-7-22-F and I only have 1.

Nice Discovery ! I have may some ambiguity in my system in translating vendor data formats (float) to (double).  I use integer arithmetic for the accounting, so I can get that to the penny. 

The double entry for the last day reflects that the back office does not know the trade at the close, so it posts equity as if the trade is still on.  A while later, the back office knows the trade and posts the adjustment.

Tue, 13 Sep 2005

CAGR Computation

Ed,

I wonder if you've changed something in computation of CAGR. I obtain your results in 200/50, 300/50, 400/50 tests ( respectevely 0.0512, 0.0936, 0,1424), but in the latest ones you published (150/15 and 325/85) they're different.

Yes, see the Reference Library link, above.

Mon, 12 Sep 2005

Typos

Ed,

FYI,

1. The copyright under the your banners is still 2004.

2. At:

Nice Catch !

Mon, 12 Sep 2005

Good Work !

Mon, 12 Sep 2005

ATR Risk Multiplier Parameter


Ed,

On the TSP page Ed Writes: "You might also notice that you make the most money with a slow system with a high heat and low ATR multiplier, although this configuration also delivers very large drawdowns."

Also, from your system math document you list the system parameters as:

Fast Lag Time Constant
Slow Lag Time Constant
ATR Time Constant
ATR Risk Multiplier
Skid Fraction
Heat

I suggest that ATR Risk Multiplier  is not an actual parameter, but rather just a convenient way to adjust heat. We can get the exact same results by setting the multiplier to 1 and setting the heat higher.

Traders sometimes think in terms of 1-ATR, 2-ATR's, etc when discussussing stop placement, as in, "I have my sell stops 2-ATR's below the market and my buy stops every 1/2-ATR above."

Traders also think in terms of overall portfolio heat, patricularly for systems that (1) have multiple entries or do not use ATR at all.

In the Simple EA System, these parameters combine as a quotient, Q=(Heat/ATR), so, as you point out, you can get all test combinations by varying only one of them.

Per your example:
h=0.1/A=5 ==> Q=.02
h=0.5/A=1 ==> Q=.50
These do not appear to be the same.

Mon, 12 Sep 2005

Matches to the Penny

Hi Ed,

I confirmed your results down to the penny. Included two screenshots of the 15/150/0.1 and 85/325/0.1 run. I did have to modify my CAGR function according to your math document. (I did my calculation based on years without fractions.) Source code: form1.cs

Sun, 11 Sep 2005

Sun, 11 Sep 2005

Good Work !

Sun, 11 Sep 2005

Results Match

Ed,

This spreadsheet includes my verification of your 85/325 EA cross system. My numbers agree with yours with the following exceptions:

My testing software displays trade P/Ls and equity amounts to the nearest dollar, not to the penny. However, it does preserve trade P/Ls down to the penny for internal calculations, only rounding the final result for display purposes. Therefore, my spreadsheet shows some very slight differences from your results. My ending equity is $13,551,819 compared to yours of $13,551,818.75, for a difference of 25 cents. This is 100% attributable to rounding the ending equity to the nearest dollar.

Additionally, although my trades and equity values match yours, my software reports a compound annual growth rate of 12.10% over the test, whereas yours is 11.21%. I confirm the way that my software calculates CAGR. It is easy to get slightly different results depending on the method for deciding how many annual periods are in the test, as well as when the test starts and stops.

My software seems to measure from the time that the first trade enters to the last day of the test. I find it more intuitive to use the first day of the test period (4/21/1982), rather than the day of the first trade inception.

Good Work !

Fri, 9 Sep 2005

The Exponential Average is not an average. It is a lag. The initialization scheme is arbitrary. I initialize the lags on the first close. I do not wait 20 days to initialize it. I wait 20 days before trading so the lags can separate. In theory, exponential lags with different initializations never converge. For practical purposes, they converge at about three time constants. The purpose of the exercise is to check the logic of the systems, to set a foundation for more complex studies. 

Perhaps you can find a workaround for TradeStation.

Fri, 9 Sep 2005

More TSP Optimizations

Ed,

I ran some more tests on the S&P sample data file from your Trading System Project page.

I include a spreadsheet in a Zip file because it is too large to email otherwise. I am not sure if it will download from your site or not. I know the last one did not.

There are two graphs, one 3D and one 2D. They both represent the same data set. The 3D chart makes it easy to see where the peaks and valleys are, especially when you grab one corner of the chart and rotate it around to view from a few different angles. The 2D chart tends to be good for finding the exact fast and slow EA values that correspond to a point on the chart. These charts cover the parameter space that showed the highest peak on my broader test from a few days ago. The Fast EA time constant steps from 70 to 100 by 1s, and the Slow EA time constant steps from 300 to 360 by 1s.

The neato thing about these charts is that by manipulating the pulldown menu labeled "% Volatility" you change the heat level of the results you are viewing on the chart. You can adjust it from 5% heat to 50% heat in 5% increments. As long as the heat level is set the same on the 2D and 3D charts they use exactly the same color schemes and you can easily see what EA values correspond to peaks and valleys on the 3D chart.

I find it interesting to note that the charts retain the same general shape across different heat levels, but the optimal parameter values (the ones that produce the highest frequencies) do tend to shift a bit.

At the highest heat of 50%, the optimal parameters look to be about 97 and 315. At the lowest heat of 5% the optimal parameters are about 80 and 335.

Though these parameter sets are rather close to one another, it does imply that perhaps the "right" parameters to trade vary with heat.

Another take on it is that a system that shows much different shaped graphs for different heat levels might be prone to more "drift" of the optimal parameter set than a system where the shape of the graph doesn't change much with heat.

It is also interesting to note how many variables there are and how much computing power it takes to explore even relatively simple systems in depth. They don't get much simpler than this one: 1 market EA crossover system. However, this latest test to explore the sensitivity of a combination of Fast EA, Slow EA, and Heat requires over 18,000 individual test runs. This is over a relatively small parameter space, and we haven't even touched the other parameters of ATR averaging period, ATR multiplier, or Skid assumption yet.

Fri, 9 Sep 2005

I like to call high-heat approaches "Phoenix Systems."  They seem to keep rising again from their own ashes.  Aggressive entrepreneurs tend to favor Phoenix Systems.

Tue, 6 Sep 2005

More EA optimization

Hi Ed,

Ed Writes:

Nice job. I like your insight that optimal heat is likely above trader tolerance. That provides a kind of mathematical proof that system trading is largely psychological.

I wonder if you have a theory to explain the relatively straight line from (100,100) to (400,400) that seems to separate your chart into two distinct regions.

You might consider using a color scheme that relates value to brightness so you can see the peaks and valleys without having to refer to a legend.

I include here new graphs of my EA optimization that incorporate your suggestions. I provide both PDF and word formats in case one is easier for you to work with than the other.

For these graphs, I go with a deep water / shallow water color scheme. The darker blues represent lower bliss functions (deeper water) and the lighter blues represent higher bliss functions (shallower water).

I also provide the graph in 3D form.  This highlights the peaks and valleys, but it is easier to refer back to the 2D graph when you want to see exactly what the fast and slow EA time constants are that correspond to points on the 3D graph.

The relatively straight line separating the chart into two regions represents the point where the fast and slow EA time constants are the same.

There are no trades when the time constants are equal because no cross occurs. The area to the lower right of this line represents tests where the fast EA time constants are greater than the slow EA time constants. The result is a kind of "countertrend" system that goes long when the EA with the shortest time constant crosses *below* the longer EA. It is a validation of trend following principles that such systems seem to perform markedly worse than systems where the fast EA time constant is less than the slow EA time constant.

Nice Graphics !

Mon, 5 Sep 2005

Going for the Heat

Yes, managing the interface between the mind and the stomach is an essential task of trading.

Mon, 5 Sep 2005

Reproduction of Exponential Moving Average Values

You might have a look at Reference Library, above, for more information on Exponential "Averages."

Sun, 4 Sep 2005

Nice Job !

Sat, 3 Sep 2005

Additional Thoughts on Exponential Smoothing

Ed,

Changing my formulas in the Excel test file to:

ESt = ESt-1 + (Closet - ESt-1)/((Time_ Constant + 1) / 2)

allows me to match your Log numbers within +-0.01 and makes the Excel math match your Log file, which I think that would be rounding issues or something like that. I will try rewriting the function in Trader's Studio now. It looks like the default xAverage and MyEMA in TradersStudio does NOT divide by two, because they got results close to my custom Function without the divide by two.

Something you might make clear in your writing is that the

(n + 1) / 2 factor is an arbitrary convention used by some software (and not by others) to make a 200 period Moving Average and a 200 period Exponential Average track closely to each other and thus be similar to each other with the Exponential Average tracking the latest numbers better.

But using the (n + 1) / 2 convention in the formula means a 200 Exponential Average is really a 100 Exponential Average, because it really moves 100th of the way towards the latest Close.

I think the word "Average" should not be used with "Exponential" at all, and that Exponential Smoothing should stand alone as it's own system and not forced to behave like a Moving Average by dividing it by 2, but apparently the industry already has adopted this standard.

Since your book uses Exponential Smoothing a lot, it might be a good idea to explain why the (n = 1) / 2 was adopted (or falsely adopted) and that some systems use it, and some systems don't, and that since the actual math in these software packages is not disclosed; that the use or non-use of the (n = 1) / 2 convention could give different results than expected when a user does not know for sure which convention the software is using.

See the Reference Library, above, for additional commentary on the EA / MA comparison.

Sat, 3 Sep 2005

Exponential Average Crossover Log Delta Questions

Ed,

I did notice the EA_Time_Constant = (MA_Averaging_Time +1)/2 formula, but it is not up with the Exponential Average. The use of “MA_Averaging_Time” is misleading. Also, It is in the Moving Average section where you say “To acknowledge this effect, some versions of testing software incorporate this formula. This formula brings exponential averages in line with moving averages for tracking ramps (linear markets). It does not bring MA and EA together work for steps, sinusoids or real markets.”

Because of where the (n + 1)/2 formula was located and the text around it, I didn’t think you were using it in the formula EAt = EAt-1 + (Closet - EAt-1)/Time_ Constant

I did some modeling (see attachment) (Ed:the winmail.dat file does not download) about when the MA starts and the results of using 104 days or 200 days, or varying the start date. I notice that changing the days calculated from 104 to 200 days gets different results no mater when each are started. I also notice that they eventually converge (with rounding) at 379 days for the Fast EA and 1467 days for the Slow EA.

My confusion about all this comes from the use of the word “Average” in Exponential Average. You have said before that Exponential Average is not really an Average, but the use of the word Average still hooks me as a reader.

Perhaps the word “Smoothing” is a better choice to eliminate reader confusion, and that Exponential Average should be replaced with Exponential Smoothing in your writing. You should say that you use the words “Exponential Smoothing” when others use the words “Exponential Average”, but then you should not use the words “Exponential Average” again in your book. When I read in another book about Exponential Smoothing and saw the (n + 1)/2 in that formula, I began to see where I might be in error. Anyone who is thinking “Average” will not intuitively divide the number of days by two.

Also, I do not intuitively understand why there is the “+ 1” in the (n + 1) / 2 formula? In the other book he gave both examples: n / 2 and (n + 1) / 2 and said that different software calculate it in these two different ways. Why is the “+ 1” in the formula?

If the (n + 1)/2 is used, it should be in the formula for Exponential Smoothing (ES) as something like.

ESt = ESt-1 + (Closet - ESt-1)/((Time_ Constant + 1) / 2)

The bottom line is that I should be using the formula above, correct?

You can easily argue that the Terms Exponential Average and Moving Average are both unfortunate choices.  Pragmatically, you might consider getting it absolutely straight in your own thinking so as to be immune to the general confusion on the topic.

Sat, 3 Sep 2005

Processing Metrics Files

Hi Ed,

I am pleased to see the Trading System Project.

I processed the metrics files (Metrics_0-0.txt, Metrics_1-1.txt and Metrics_2-2.txt). There appears to be some minor discrepancies between the results posted (Three Runs) and values derived from the metrics files.

My drawdown calculation is a bit off.

Which entries in the metrics files are used to determine the drawdown calculation?

Here are my results:


File: Metrics_0-0.txt
Maximum percent draw down:

High:
Line Number->1354
1987-08-26-Wednesday OHLC:[298.70 298.95 295.30 296.10 ] slow=252.999 fast=279.769 Atr=4.298 Eq=1808922.43

Low:
Line Number->1392
1987-10-20-Tuesday OHLC:[178.35 199.35 138.35 173.60 ] slow=258.389 fast=267.766 Atr=19.677 Eq=957057.46

End = 3181650.20
CAGR = 0.0510
Exponential Final Value = 9172467.3385
DrDn = 0.8901 = (High/Low)-1 = (1808922.43/957057.46)-1
Bliss = 0.0573 = CAGR/(DrDn)
Years to Recover = 17.4408 = 1/Bliss
Lake Ratio = 0.1845


File: Metrics_1-1.txt
Maximum percent draw down:

High:
Line Number->1354
1987-08-26-Wednesday OHLC:[298.70 298.95 295.30 296.10 ] slow=240.977 fast=279.769 Atr=4.298 Eq=2541318.80

Low:
Line Number->1392
1987-10-20-Tuesday OHLC:[178.35 199.35 138.35 173.60 ] slow=247.609 fast=267.766 Atr=19.677 Eq=1054046.37

End = 7946810.74
CAGR = 0.0932
Exponential Final Value = 9172467.3385
DrDn = 1.4110 = (High/Low)-1 = (2541318.80/1054046.37)-1
Bliss = 0.0661 = CAGR/(DrDn)
Years to Recover = 15.1339 = 1/Bliss

Lake Ratio = 0.1856

File: Metrics_2-2.txt
Maximum percent draw down:

High:
Line Number->1354
1987-08-26-Wednesday OHLC:[298.70 298.95 295.30 296.10 ] slow=231.316 fast=279.769 Atr=4.298 Eq=3140484.79

Low:
Line Number->1392
1987-10-20-Tuesday OHLC:[178.35 199.35 138.35 173.60 ] slow=238.163 fast=267.766 Atr=19.677 Eq=1171419.87

End = 21863170.99
CAGR = 0.1419
Exponential Final Value = 9172467.3385
DrDn = 1.6809 = (High/Low)-1 = (3140484.79/1171419.87)-1
Bliss = 0.0844 = CAGR/(DrDn)
Years to Recover = 11.8485 = 1/Bliss
Lake Ratio = 0.1542

DD% = largest of [drawdown / previous_peak]

Sat, 3 Sep 2005

Exponential Average Crossover Log Delta Questions

Ed,

I was looking up Exponential Average in my books and just wanted to confirm what you mean by "Time_Constant" in your formula. In a book Exponential Smoothing uses "2/DaysForEmCalculation".

That may be my problem if "Time_Constant" in your formula is not equal to DaysForEmCalculation. Which would be 200 for the Slow Average and 50 for the Fast Average in Run 0.0.

Use:  Exponential_Lag =  (Moving_Average_Time + 1) /2.  See the Reference Library, above.

Sat, 3 Sep 2005

Exponential Average Crossover Log Delta Questions

Ed,

I cannot get the same results as your Trade and Metrics Logs for Run 0.0.

I have tried the Trader's Studio standard code xAverage and MyEMA for two different ways to calculate Exponential Average and have even written a third calculation special function in Trader's Studio with the following formula:

EAt = EAt-1 + (Closet - EAt-1)/Time_ Constant

Called EdSeykotaEMA and I cannot match your Log results. All 3 of these formulas get results that are close to each other but all are nowhere close to your Log results.

Proof of the mismatch is in the attached Excel file which uses the same formula above.

Also, if I calculate the Exponential Average using the formula above I can't match the Log file itself. So it appears to me that the results of the log file are not from using the exact formula above. It doesn't appear to be rounding or significant digits error.

I must be doing a math error, if other people are getting the same result, but I am using your formula for the math both in Trader' s Studio and in Excel. So I don't know how I could be getting different results.

Many people are getting the same results I get, allowing for rounding errors, likely on my side.  You might check the Reference Library, above, for information on the (N + 1)/2 adjustment factor.  I consider it an honor to have an equation bear my name, even if it is dysfunctional.

Fri, 2 Sep 2005

TSP Optimization

Ed,

Here is a spreadsheet (does not seem to download) that shows the results of my optimization of the EA Crossover system for your sample data file. In this test I hold all parameters constant at the same values you do in your first example (heat, ATR averaging time, ATR multiplier, skid) except for the fast and slow EA time constants.

The spreadsheet shows a graph of values of the bliss function (aka frequency or MAR) against different combinations of fast and slow EA time constants. It is labeled, "Bliss vs. EA Time Constants." The highest frequency appears between fast values of 60 to 110 and slow values of 280-380.

The chart labeled, "Detail Optimization Chart" shows this parameter space more closely. The data for the previous graph represents tests where the value of the fast EA steps 10 units between test runs and the slow EA steps 20 units. This chart shows finer granularity with a fast EA step of 2 and a slow EA step of 5.

The optimal combination of fast and slow EA time constants appears to be about 80 and 335. There are several other values in the same general area of the graph that give similar results.

Note that various time constant combinations might respond differently if I vary any of the other system parameters that are unchanging in this test. In particular, frequency tends to increase with heat up to a point.

The optimal frequency generally occurs at a heat level that is greater than the most traders' heat tolerance.

Also, slower systems that take fewer trades are typically less volatile (they have lower returns and smaller drawdowns) for the same heat level as faster systems that take more trades. Of course, adding more markets to the simulation would likely alter the optimal parameter values as well.

-----

PS - You can look at the two sheets labeled "Data" and "Detail Data" for more information about the results for any individual parameter pair.

Nice job.  I like your insight that optimal heat is likely above trader tolerance.  That provides a kind of mathematical proof that system trading is largely psychological.

I wonder if you have a theory to explain the relatively straight line from (100,100) to (400,400) that seems to separate your chart into two distinct regions. 

You might consider using a color scheme that relates value to brightness so you can see the peaks and valleys without having to refer to a legend.

Wed, 31 Aug 2005

TSP


I'm looking at a matrix of results and notice that many of the short term systems lose serious money over the entire period. I reduce skid to 0 and notice that many of the short-term systems still lose money (including the popular 5/20 combination). Even with no skid short-term systems are less profitable and with 50% skid short term systems are extremely hazardous. I decide to consider only systems with longer time constants and I run a search for the parameters that achieve the highest bliss.

I vary the parameters as follows:

slow averaging time: 100 to 900 in steps of 100.

fast averaging time: 25 to less than the slow averaging time in steps of 25

heat: 0.05 to 0.25 in steps of 0.05

I find the most blissful system might be:

slow averaging time = 800
fast averaging time = 25
heat=0.25

end = 32308318.75
cagr = 0.161
dr-dn = 0.577
bliss = 0.2795

A local maximum in that neighborhood appears to be at slow=826 and fast=20.

There are no losing trades in the results so the more you bet the more you make ;-)

I'd like to know how to find a margin clerk who is willing to go along with your "the more you bet, the more you make" strategy.  You might try for an optimal solution for initial margin = 10% of value and maintenance margin at half that.

Wed, 31 Aug 2005

Exponential Average Crossover Reproduction

Ed,

I continue to work on the Trader's Studio code to reproduce your results. I find that two different ways to calculate the EMA generate the first trade on 9/14/1984 or on 10/12/1988 in my two ways to calculate the EMA.

When I look at the raw data file, the first date is 19820421, and your first trade is 3050 units on 9/16/82; only 104 trading days from the beginning of the data file. How is it possible to do this with a 200 day EMA? Don't you need 200 days before the first Slow Average Time line can correctly be used to take a trade?

You can prime an exponential with any value.  See the section on EA for more information.

Wed, 31 Aug 2005

TSP Tutorial Result

Hello Ed,

Here are my results from the TSP EA tutorial. I wrote a test program in C# and confirmed your results. I do have a few comments on your test results though.

I have a problem getting the CAGR and the end result to compare 100% with your runs. My results always come a few cents below or above your result. The reason for this seems to be a strange rounding error in either mine or your program. (Maybe not an error but at least an issue, I am not sure which program do the calculation right.) Look at example 1.1 and at date 82-08-20, there the open price should be 122.475 (you round it to 122.48, but I assume that that is only for presentation.) On the 82-08-21 the equity is: ( 123.35 – 122.475 )* 6400 = 5600 and not 5999.99. When we close the position on the 84-03-16 the profit is (153.2-122.475)*6400=196640. You show a profit of 192799.80. This might be the cause for the CAGR calculation to not be 100% exact.

The program also brute-force optimizes the slow/fast averages and the heat variables. I will start the testing today, but my first test showed a good Bliss when using the following parameters: Fast: 44 / Slow: 410 / Heat: 1.0 :) But I think that will not be suitable for the system …

You need a Windows machine with .NET framework to run this program.

Also, I really enjoyed your book. I am trying to get a few people to start a tribe here in Sweden, but so far no luck ... I will report back when I get a few people here.

Nice presentation.

Tue, 30 Aug 2005

Equity Column

Hi Ed,

I write a program to reproduce your results. I compare your results with mine. I think there might be a problem with the equity column in your metrics log. For example, the equity values in your Metrics_0-0.txt file appear to be for a now that is one day earlier than the other metrics that appear on the same row. For the system rules you give this does not affect the trades since the equity value stabilizes before the system uses it to size the next position.

Except for this discrepancy the differences in the results of our simulations are all due to different rounding. For position sizing, I use an exact rounding to the nearest 50 units. Our (trivial) differences might best be explained if you are using floating point for the number of units and have inexact rounding.

My ending values:
Run 0.0: 3194250.00
Run 1.1: 8001410.00
Run 2.2: 22098018.75

Per your comments, I plan to clarify the definitions of the columns as to which are morning values and which are evening values.  I plan to re-run the simulation at higher precision.

Tue, 30 Aug 2005

EA Trading System

Dear Ed,

Thank you for the Trading System Project.

I was able to duplicate your results using Excel down to the third
decimal. From the fourth decimal my results (4 meg excel file) are slightly different probably due to rounding.

I also optimized for Bliss. My optimal solution for Heat = 0.15 is Bliss = 0.255, at Slow EA = 800 and Fast EA = 25. However, CAGR is only 0.097. Also, this result is an outlier.

A better result may be Slow EA = 950 and Fast EA = 45 which gives Bliss = 0.2322. Please see the attached file for a 3D model of the results. I averaged the results from adjacent data points to come up with a more meaningful solution.

How would a system like this hold up in actual trading? I mean, how much should I expect CAGR and DD to differ from historical test results?

I would appreciate any feedback or comments you may have.

Per your comment, I plan to re-run the simulation at higher precision.  I do not know what you should expect.  Nice presentation of Bliss = f(slow, fast).  I wonder if you can get an optimal solution for Bliss = f(slow, fast, heat)

Tue, 30 Aug 2005

FAQ


Dear Mr. Seykota,

I have a question regarding the EA cross-over system in your TSP:
When do you reenter a position after your ATR exit stop has been triggered, but the cross-over system is still on a buy signal?

This system does not use an ATR stop.  It uses ATR to compute a virtual stop in order to estimate entry risk per contract and position size.

Mon, 29 Aug 2005

EA Crossover System Verification


Hi Ed,

I am including an Excel spreadsheet that contains my verification of the test runs you recently post to the Trading System page.

Here are some things I have to figure out before I can duplicate your results:

1. What kind of exponential lag math are you actually using, and how do you "prime" the EA?

The webpage indicates you calculate the exponential lag by the formula -

EAt = EAt-1 + (Closet - EAt-1)/Time_ Constant

My efforts indicate that a modification to this expression is necessary for the time constants you use in your example runs to produce the results you report. The modification is as follows:

EAt = EAt-1 + (Closet - EAt-1)/((Time_Constant + 1) / 2)

When I put the time constant of 50, for example, into the first
expression and I assume a previous EA value of 117.45 and a current close of 117.90 (the first data points in your example files), I get a value of 117.459. This does not match your output, nor do the other values that result from applying this expression for each bar of the data file.

If I plug the same numbers into the second expression, I get a value of 117.467647. This matches your output. This holds for every value of EA throughout the test.

Concerning the priming value: I match your test results when I use the first closing price in the data file for the initial EA value.

2. What kind of point values are you using for the S&P?

1. I use the (N +1)/2 adjustment and I prime the Lag with the first close. 

2. I am using a $1 point value and buy in 50-lot multiples. Per your comment I plan to re-run the simulation with 250-lot multiples.

3. I have the skid fraction as a test parameter, so I can run sensitivity tests on skid.  I expect long-term systems to be insensitive to transaction costs, short-term systems to be sensitive to transaction costs.  I do not round up or down on fills.  In actual trading, I experience split fills with average prices at non-tradable levels.