How to BACKTEST GET-ElliottWave-Study

[fcarstens]

Hello there!

First af all I'd like to introduce myself:

My name is Florian and I'm from Germany (as you may fast mention by reading my post...!?).

Although I'm a computer scientist now I'm seeking for a new opportunity to get professional in.

I have red your threads carefully and also tested the eSignal tool very well.

BUT THERE IS SOME BIG ISSUE (PROBLEM) THAT HAS OCCURED!

I tried to backtest the formula formerly posted in this forum (it was about the GET-ElliottWave-Study, where a Buy/Sell Signal is triggerd after breaking the MA3 high(LONG) or low(SHORT) while beeing in a specific wave! written by Matt Gundersen)

So I added some strategy code to this study and it comes out that the backtesting does not go further back in time then the number of bars provided to the GetElliottStudy(300,...) (in this case 300).

But when I increase the number of bars, there is a change of back testing results, because IMO the calculation of the ElliotWave algorithm has changed (now calculating new waves on a longer period of time for instance 660 for one day in a 1 min. chart).

So how can I go an with that really important issue, because I really would like to do some "fancy" programming within eSignal and see results on several parameters...

Thanx for your efforts,

Florian.

P.S.: Really enyoed the tools and this forum so far!!!

[gspiker]

Hi,

What you say is true about backtesting with GET waves. The issue (I think - after playing with this for a LONG time with the backtester and in replay mode) is, as you give GET more data it will have a different idea on what wave count you are on. In otherwords if I start my analysis at bar -300 and it happens that the chart is in the middle of a wave 3, it might not know that because the middle of a wave three could be the middle of ANY impulse wave. I have given the backtester nohistorical context before bar -300 to determine what impulse wave we are on. If then start my analysis at -600 suddenly I have more historical context. So that is one possible issue

Another issue: One thing you never want to do is tell GET to look back more bars than you are providing in your timetemplate for the backtest (or even for regular use). Your results will be very odd.

There also are issue surrounding how the backtester works. This is not GET specific issues, but it does have specific implications for backtesting some GET features. I am hoping someone at eSignal is working on it, as the backtester can provide false results because of this. The problem is that the backtester iterates all the bars first and then runs the .efs code on the results. However not all indicators keep a list of their historical values, so for example if you request PTI values in your backtest, you will get only the most recent PTI value back, even if you asked for the PTI value back at bar -1200, you wll get the PTI value for bar 0. Clearly this can skew the results. The backtester should work more like replay mode, with no knowledge of what will happen in the future.

Lastly, don't forget that with GET wavecounts, they can change on you so your logic has to be able to deal with this. Only Matt's most recent postings of accessing the GET linetools via EFS has shown ways of dealing with changing counts.

[fcarstens]

Hello gspiker!

Thanx for your quick and detailed response!

It confirmed my right interpretation of this issue!

So with that in mind I maybe will try to implement my own backtesting within the study code.

When I have a routine that calculates my profits/losses and logs it to a file I could start somewhere in time within the chart and start the replay (1/2 sec) and wait for an amount of time to finish calculation. This should provide some "true" results on that what I try to achive...

Do you think so too, or ar there any concerns/hints on that?

[gspiker]

Hi,

I started down the path of doing exactly what you say here. I quickly found out (by playing) that replay mode has a few bugs, which GET aggravated.

I talked with Matt about two week ago asking if these bugs were fixed, and he indicated that they were fixed in the prebeta version...so my guess is they are also fixed in the beta version out now (it was based on that prebeta).

I have not tested this.

Garth