Charlton's Programmed Trade Development

[Charlton]

sounds good.. Use a CG Oscillator with Homdyne Discriminator on 1min, 3min, 5min, 10min 30min and 60min. When all 6 time frames line up enter top three N minute stocks. code runs 2:30 - 4:30 & 7:30 - close.
now we just need to talk to charlton nicely to get him to code it.. lol

belflan

Belflan

I will take a look, perhaps this could be the first module, just to give us some signals. I have been away for 2 days, so it is a bit of a shock how fast this is moving.

Keep the good suggestions and definition of the logic coming. There may be a case for some sub-threads to cover each area such as this.

This is in many ways far harder than the coding itself. Basically if you can define the logical steps and trade it manually, it can be programmed.

Charlton

 

[lote_tree]

Great thread Charlton, really looking forward to how this all develops.

I've done some research into the area of more advanced oscillators, specifically the works of John Ehlers. He seems to be one of the main authorities when it comes to the creation of very advanced adaptive indicators.

I've been looking at his ideas on "Fisherized" (Fisher Transform) oscillators. The three main oscillators he seems to recommend are:

Fisher Cyber Cycle
Fisher CG (Centre of Gravity)
Fisher RVI (Relative Vigor Index)

I haven't had chance to test them yet but I've enclosed the ELA code for all three oscillators to get the ball rolling.

There are Stochastic versions of the same oscillators that work equally well according to Ehler. If anyone is interested I can post the codes for them as well.

This is an excerpt from his book, CYBERNETIC ANALYSIS FOR STOCKS AND FUTURES (2004):

"It appears that the Fisher RVI is the superior oscillator because, almost without exception, it provides trading signals several bars in advance of the other indicators(refering to Fisher Cyber Cycle and Fisher CG). That makes it a really good indicator because the other two are not slouches in their own right. Any or all of the three can be a profound addition to your technical analysis tools."

He strongly suggests that we should test each of them out and see which oscillator works best for our needs. I'll be looking to test the Fisher RVI this week. I'll report back with my findings.

Cheers

Naeem

 

[Charlton]

Charlton

I have been programming for roughly 25 years - since I was 13 & I now run a software co in Bangkok.

First of all - I think the specific oscillator we use is irrelevant - we can write the code in such a way we can plug in a better oscillator later. I think there are larger challenges than that.

Absolutely agree - you more than most people are well aware of the way these things should and can be built and also the types of issues involved.

The oscillator evaluation is really part of requirements gathering/tool selection and can be an independent piece of work run in parallel and, already we have various suggestions on what to look at

First - TS processes ESL scripts 'bar by bar' or 'tick by cick' - what I can't fathom is how you have an ESL that can monitor an oscillator on multiple time frames. I can use data1, data2, data2 etc - and have oscillators on all - but this ESL runs 'per bar' - so if I have multiple time frames being monitored - how do you really make sense of an oscillator at 60,30,10,5,3,1 ? I just don't understand the timing cycle of ESL in a multi-timeframe environment - I just don't conceptually understand how it's achieved and how you apply oscillators that go back x bars when you have multiple timeframes. I almost feel that TS isn't up to the job from what I've learnt so far.
.

There are 2 approaches. Within one chart window you can have multiple sub-charts each using different data compression and it is possible to create conditions using values pulled from multiple sub-charts.

Furthermore it is possible to pass data between multiple windows. Some code was published on this forum to display a radar screen showing values from 3 timeframes. I will attempt to find the link to that post later. The values were made available to the one composite radar screen making use of globalvariable.dll

Second - N Minute change works off radar screen yet I can't see a way in TS to tell radar screen to change the data compression - is this actually possible in radar screen ?

I'm not sure whether you are talking about manually changing data compression or automating this. To manually change data compression in radar screen (TS8.3) you simply highlight the symbol column and then Format > Symbol.

The code for calculating the data compression during the session has been provided to us. For changing the data compression within further functions I believe we could use the function BAR INTERVAL. However I have not yet tried this, so it is still supposition.

Pete - you have raised some very valid points here and my initial thoughts as described above is that they are not insurmountable. Clearly the technical feasibility of what I have suggested just needs to be proved by some simple working examples, so that is one item to add to the list. By the way are you working with TS8.3 or TS2000ki ?

Any assistance you can bring to the table will be welcome and invaluable

Thanks

Charlton

 

[dcraig1]

Great thread Charlton, really looking forward to how this all develops.

I've done some research into the area of more advanced oscillators, specifically the works of John Ehlers. He seems to be one of the main authorities when it comes to the creation of very advanced adaptive indicators.

I've been looking at his ideas on "Fisherized" (Fisher Transform) oscillators. The three main oscillators he seems to recommend are:

Fisher Cyber Cycle
Fisher CG (Centre of Gravity)
Fisher RVI (Relative Vigor Index)

I haven't had chance to test them yet but I've enclosed the ELA code for all three oscillators to get the ball rolling.

There are Stochastic versions of the same oscillators that work equally well according to Ehler. If anyone is interested I can post the codes for them as well.

This is an excerpt from his book, CYBERNETIC ANALYSIS FOR STOCKS AND FUTURES (2004):

"It appears that the Fisher RVI is the superior oscillator because, almost without exception, it provides trading signals several bars in advance of the other indicators(refering to Fisher Cyber Cycle and Fisher CG). That makes it a really good indicator because the other two are not slouches in their own right. Any or all of the three can be a profound addition to your technical analysis tools."

He strongly suggests that we should test each of them out and see which oscillator works best for our needs. I'll be looking to test the Fisher RVI this week. I'll report back with my findings.

Cheers

Naeem

FYI, you can get the code for these here:

Cybernetic Analysis for Stocks and ... - Google Book Search

which is useful for anybody not using TS and wanting to convert EL to something else.

 

[lote_tree]

FYI, you can get the code for these here:

Cybernetic Analysis for Stocks and ... - Google Book Search

which is useful for anybody not using TS and wanting to convert EL to something else.

Good one matey. Unfortunately some of the code is missing from google. I have a full copy of the book. For those who don't use TS please PM if you want the full EFS code. I don't know whether it's legal to post them directly on the BB.

Cheers
Naeem

 

[leovirgo]

Charlton

First - TS processes ESL scripts 'bar by bar' or 'tick by cick' - what I can't fathom is how you have an ESL that can monitor an oscillator on multiple time frames. I can use data1, data2, data2 etc - and have oscillators on all - but this ESL runs 'per bar' - so if I have multiple time frames being monitored - how do you really make sense of an oscillator at 60,30,10,5,3,1 ?

I use Radar Screen pages to send MLT signals. I have 1minute, 3 minute, 5 minute etc pages in RS whereby GV.DLL read and send numerics/strings only when the bars close, i.e, no intrabar analysis is done in individual TFs. Then I receive them in one indicator with GV.DLL. Grey1 already used that in his exhaustion engine. The receiver indicator reads them tick by tick. No charts required.

In this way we can line up readings from multi TF in RS. We should avoid using charts if possible.

 

[Charlton]

I use Radar Screen pages to send MLT signals. I have 1minute, 3 minute, 5 minute etc pages in RS whereby GV.DLL read and send numerics/strings only when the bars close, i.e, no intrabar analysis is done in individual TFs. Then I receive them in one indicator with GV.DLL. Grey1 already used that in his exhaustion engine. The receiver indicator reads them tick by tick. No charts required.

In this way we can line up readings from multi TF in RS. We should avoid using charts if possible.

The exhaustion engine code is discussed in a message from Trader333

http://www.trade2win.com/boards/394058-post34.html

The code is attached. It also requires the global variable dll to be downloaded and I attach a copy provided by Trader333 on 12-jun-2008

This is one aspect to consider for programmed trading - do we wait for all relevant bars to close or consider them during formation. This was discussed at the last seminar - closed bars provide "cleaner signals" , but bars under formation can give earlier yet riskier signals.

Charlton

 

[pedro01]

Absolutely agree - you more than most people are well aware of the way these things should and can be built and also the types of issues involved.

The oscillator evaluation is really part of requirements gathering/tool selection and can be an independent piece of work run in parallel and, already we have various suggestions on what to look at

There are 2 approaches. Within one chart window you can have multiple sub-charts each using different data compression and it is possible to create conditions using values pulled from multiple sub-charts.

Furthermore it is possible to pass data between multiple windows. Some code was published on this forum to display a radar screen showing values from 3 timeframes. I will attempt to find the link to that post later. The values were made available to the one composite radar screen making use of globalvariable.dll

I hear you - on the same data in multiple charts, it gets a tad messy & you are reliant on getting charts on there manually all in the same sequence. Plus - I still dont quite get how you suppress a calculation on the 5 min bar when each 1 min bar is being processed as the ESL itself will need to be on the lowest time frame. This to me seems the approach with the highest potential processing overhead.

On the othe hand, global variables, do seem a cleaner, lower overhead way to do things. Although I still haven't used global vars yet - something I need to brush up on. We just need to keep the global variables nice & simple.

I'm not sure whether you are talking about manually changing data compression or automating this. To manually change data compression in radar screen (TS8.3) you simply highlight the symbol column and then Format > Symbol.

The code for calculating the data compression during the session has been provided to us. For changing the data compression within further functions I believe we could use the function BAR INTERVAL. However I have not yet tried this, so it is still supposition.

I was referring to the automatic changing of the interval. I did see the code whereby it was merely changing the calculations and always using 1 minute but I am not convinced you can call canned indicators & still get the correct result using this. I need to try auto setting bar interval but such a thing would require TS to go back & start processing again (e.g. if you use 14 bars back & reset the compression, it needs to go back to bar1 1), something I haven't seen in the manuals. This is something we can do manually to start with.

I think the key is -
- getting the basket of stocks to trade built
- being able to specify the risk based on the daly fundamentals (not necessarily automated).
- pulling the trigger based on the basket of stocks.

Pete - you have raised some very valid points here and my initial thoughts as described above is that they are not insurmountable. Clearly the technical feasibility of what I have suggested just needs to be proved by some simple working examples, so that is one item to add to the list. By the way are you working with TS8.3 or TS2000ki ?

Any assistance you can bring to the table will be welcome and invaluable

Thanks

Charlton

OK - so where shall we start ? As I see it - we can either start on the radar screen side (which stocks to buy/sell short) or on the cycle indicator side - (when to buy/sell short).

It seems obvious to me that we have the skills to do this & that Charlton is an adept developer, let's decide that & then build the code.

 

[pedro01]

The exhaustion engine code is discussed in a message from Trader333

http://www.trade2win.com/boards/394058-post34.html

The code is attached. It also requires the global variable dll to be downloaded and I attach a copy provided by Trader333 on 12-jun-2008

This is one aspect to consider for programmed trading - do we wait for all relevant bars to close or consider them during formation. This was discussed at the last seminar - closed bars provide "cleaner signals" , but bars under formation can give earlier yet riskier signals.

Charlton

Interesting BUT - as it's protected, it doesn't give me any more clues on how to code with multiple time frames.

I don't want to be cracking Pauls code....

 

[lote_tree]

Implied Volatility Stops & Profit Targets

I was thinking about volatility stops. Iraj mentioned the VIX as a guide to using volatility stops. If we are serious about constructing advanced systems then we should obviously consider sophisticated ways of constructing stops and profit targets. I’ll throw some ideas out there.

If we adopt the premise that our market timing on entry is accurate via MLT we should reasonably expect our positions to become profitable soon after entry, especially when we are using further optimisation through the use of Iraj N Minute change.

The 10min Macci is the most critical TF for our trading. I know we are not going to be using the Macci but I’ll use that term for now. Assuming our entry rule states that we will enter a position once the 10min bar has closed and the Macci points in the direction of our trade we will want to consider a volatility stop based on the 10min TF. Thus we should reasonably expect a trade to become profitable within the 10min window. If our entry is good then price must move away from our entry and the majority of average trader's including mom and pop shouldn’t be able to get in at the same price as us, if they can, then our entry must be crap. So a time based stop coupled with implied volatility may be a solid foundation to work from when constructing automated stops and profit targets.

As we know the VIX index represents the percentage change expected in the S&P 500 12 months from the last trading session. We need to normalise that down to 10 min for our purposes:

First normalise down to 1 day: 1/365 = 0.002739

Second step is to normalise down to 10 minutes for the trading day:

(0.002739/390¹) * 10 = 0.00007024

√0.00007024 = 0.00838

Now in order to calculate our volatility stop we need our entry price and the value of the VIX at the time of entry.

E.g Apple Inc. long entry price @ 15:00pm GMT = $107
VIX Index @15:00pm GMT = 55.32%

0.00838 * 107 * 0.5532 = 0.4960

A 1 STDV volatility stop for Apple Inc = $0.50 cents

If you’re more comfortable with a wider stop you can consider the following:

0.00838 * 107 * 0.5532 * 1.5 = 0.744

A 1.5 STDV volatility stop for Apple Inc = $0.74 cents


Let’s use another example:

Joy Global Inc short entry @ 15:00pm GMT = $21.24
VIX Index @ 15:00pm GMT = 55.32%

0.00838 * 21.24 * 0.5532 = 0.0984

A 1 STDV volatility stop for Joy Global Inc = $0.10 cents

So in laymen’s terms if we use a 1 STDV volatility stop; theoretically if price probes near our stop within the next 10min after entry it has a 68% chance of reversing from our stop point based upon current market implied volatility. A 1.5 STDV volatility stop suggests an 87% probability of price reversing from our stop point based upon current market implied volatility. Obviously the higher up the STDV ladder we go the less likely our stop will be hit but the increase in risk is the trade off. However, our system edge should be enough to offset the need to increase risk and minimise the probability of our stop being hit.

This can naturally provide the framework to construct profit targets. As traders we probably expect a reasonable R:R to be around 3:1. Using the following example:

JOYG Risk = $0.10 cents, (see previous short Joy Global example)

Profit Target = $0.30 cents. So our execution rules can read:

Close 75% of the position when 30 cents in profit and move the last 25% of the position to entry + 2 cents.

So the variables that we would like to control if we decide to code this up will be the STDV stop levels and the R:R we for our profit target.

Lastly, one of the main criticisms I can potentially see with this method of stop and profit target calculation is the intrinsic volatility of stocks relative to the market. Apple may be an extremely volatile stock relative to the market by nature, hence a higher STDV value may be required to mitigate the higher probability of our stop being hit.

All in all this may open up new ideas for us to explore.

Cheers

Naeem



1. (390min represents the amount of minutes in the trading day)

 

[pedro01]

The exhaustion engine code is discussed in a message from Trader333

http://www.trade2win.com/boards/394058-post34.html

The code is attached. It also requires the global variable dll to be downloaded and I attach a copy provided by Trader333 on 12-jun-2008

This is one aspect to consider for programmed trading - do we wait for all relevant bars to close or consider them during formation. This was discussed at the last seminar - closed bars provide "cleaner signals" , but bars under formation can give earlier yet riskier signals.

Charlton

OK - I just loaded this & ran it - I ended up with 4 radar screens - one 1 with each of the MACCI indicators. I did this because MACCI_T03 needs to be on 5 min but if I put 5,3,1 on RS, it'll calculate MACCI_T03 for every interval. I reckon we'd combine the 3 MACCI_T* indicators and have them run different parts of the code based on the interval.

 

[pedro01]

I was thinking about volatility stops. Iraj mentioned the VIX as a guide to using volatility stops. If we are serious about constructing advanced systems then we should obviously consider sophisticated ways of constructing stops and profit targets. I’ll throw some ideas out there.

If we adopt the premise that our market timing on entry is accurate via MLT we should reasonably expect our positions to become profitable soon after entry, especially when we are using further optimisation through the use of Iraj N Minute change.

The 10min Macci is the most critical TF for our trading. I know we are not going to be using the Macci but I’ll use that term for now. Assuming our entry rule states that we will enter a position once the 10min bar has closed and the Macci points in the direction of our trade we will want to consider a volatility stop based on the 10min TF. Thus we should reasonably expect a trade to become profitable within the 10min window. If our entry is good then price must move away from our entry and the majority of average trader's including mom and pop shouldn’t be able to get in at the same price as us, if they can, then our entry must be crap. So a time based stop coupled with implied volatility may be a solid foundation to work from when constructing automated stops and profit targets.

As we know the VIX index represents the percentage change expected in the S&P 500 12 months from the last trading session. We need to normalise that down to 10 min for our purposes:

First normalise down to 1 day: 1/365 = 0.002739

Second step is to normalise down to 10 minutes for the trading day:

(0.002739/390¹) * 10 = 0.00007024

√0.00007024 = 0.00838

Now in order to calculate our volatility stop we need our entry price and the value of the VIX at the time of entry.

E.g Apple Inc. long entry price @ 15:00pm GMT = $107
VIX Index @15:00pm GMT = 55.32%

0.00838 * 107 * 0.5532 = 0.4960

A 1 STDV volatility stop for Apple Inc = $0.50 cents

If you’re more comfortable with a wider stop you can consider the following:

0.00838 * 107 * 0.5532 * 1.5 = 0.744

A 1.5 STDV volatility stop for Apple Inc = $0.74 cents


Let’s use another example:

Joy Global Inc short entry @ 15:00pm GMT = $21.24
VIX Index @ 15:00pm GMT = 55.32%

0.00838 * 21.24 * 0.5532 = 0.0984

A 1 STDV volatility stop for Joy Global Inc = $0.10 cents

So in laymen’s terms if we use a 1 STDV volatility stop; theoretically if price probes near our stop within the next 10min after entry it has a 68% chance of reversing from our stop point based upon current market implied volatility. A 1.5 STDV volatility stop suggests an 87% probability of price reversing from our stop point based upon current market implied volatility. Obviously the higher up the STDV ladder we go the less likely our stop will be hit but the increase in risk is the trade off. However, our system edge should be enough to offset the need to increase risk and minimise the probability of our stop being hit.

This can naturally provide the framework to construct profit targets. As traders we probably expect a reasonable R:R to be around 3:1. Using the following example:

JOYG Risk = $0.10 cents, (see previous short Joy Global example)

Profit Target = $0.30 cents. So our execution rules can read:

Close 75% of the position when 30 cents in profit and move the last 25% of the position to entry + 2 cents.

So the variables that we would like to control if we decide to code this up will be the STDV stop levels and the R:R we for our profit target.

Lastly, one of the main criticisms I can potentially see with this method of stop and profit target calculation is the intrinsic volatility of stocks relative to the market. Apple may be an extremely volatile stock relative to the market by nature, hence a higher STDV value may be required to mitigate the higher probability of our stop being hit.

All in all this may open up new ideas for us to explore.

Cheers

Naeem



1. (390min represents the amount of minutes in the trading day)

Naeem - I agree entirely & we can have a 'stop engine' that we plug in so that we can all try our own stop methods. To do this we define a 'stop' function that we call to set our stop levels. We can all then define our stop function differently.

Most important at the moment though is coding WHEN & WHATN to get in, then we will code when to get out !

So - Charlton - you are Project Manager :cheesy: - which do you want do code first - WHEN or WHAT ?

 

[Trader333]

Interesting BUT - as it's protected, it doesn't give me any more clues on how to code with multiple time frames.

I don't want to be cracking Pauls code....

It was only protected to stop changes being made and complicating things which has happened in the past and I am happy for you to have it if you wish.


Paul

 

[Charlton]

I hear you - on the same data in multiple charts, it gets a tad messy & you are reliant on getting charts on there manually all in the same sequence. Plus - I still dont quite get how you suppress a calculation on the 5 min bar when each 1 min bar is being processed as the ESL itself will need to be on the lowest time frame. This to me seems the approach with the highest potential processing overhead.

Yes it can get messy and you are correct about the importance of the sequence. Attached is a word doc and ELD file for a simple example I did in the past for someone.

On the othe hand, global variables, do seem a cleaner, lower overhead way to do things. Although I still haven't used global vars yet - something I need to brush up on. We just need to keep the global variables nice & simple.

Yes - this is probably the way to go because it is more flexible

I was referring to the automatic changing of the interval. I did see the code whereby it was merely changing the calculations and always using 1 minute but I am not convinced you can call canned indicators & still get the correct result using this. I need to try auto setting bar interval but such a thing would require TS to go back & start processing again (e.g. if you use 14 bars back & reset the compression, it needs to go back to bar1 1), something I haven't seen in the manuals. This is something we can do manually to start with.

I will discuss the technicalities of this with you via PM, rather than lengthen this particular post.

I think the key is -
- getting the basket of stocks to trade built
- being able to specify the risk based on the daly fundamentals (not necessarily automated).
- pulling the trigger based on the basket of stocks.



OK - so where shall we start ? As I see it - we can either start on the radar screen side (which stocks to buy/sell short) or on the cycle indicator side - (when to buy/sell short).

It seems obvious to me that we have the skills to do this & that Charlton is an adept developer, let's decide that & then build the code.

Agreed - I have noticed you have a later post on this matter so I will consider it there

Charlton

 

[Charlton]

Naeem - I agree entirely & we can have a 'stop engine' that we plug in so that we can all try our own stop methods. To do this we define a 'stop' function that we call to set our stop levels. We can all then define our stop function differently.

Most important at the moment though is coding WHEN & WHATN to get in, then we will code when to get out !

So - Charlton - you are Project Manager :cheesy: - which do you want do code first - WHEN or WHAT ?

First of all I must say thanks to everyone who is contributing to this thread. There are some great ideas coming out and I think we will be able to make use of much of them. Putting the project manager hat on I think we should start with the core functionality, which in my view is the cycle analysis and focussing on the perfect entry.

The reason I say this is because it could give us a tool to use first that could be an improvement on MACCI. It would also provide one of the reasons to exit a trade.

In the meantime it would be useful if others continue their investigations and discussions arount the other areas that have already been highlighted, such as stoploss, equity candidate selection, definition of strength/weakness - is cent change in relation to ATR for the equity vs INDU the most appropriate measure for example

If others do not agree that cycle analysis is the first module to consider then please suggest others and reasons why, but for me MACCI or its replacement is key to the whole concept.

Charlton

 

[evostik]

Hi Charlton

I tend to agree with your last comment.

In case this becomes of use later, the following is a working version of code that calculates and plots the current Dominant Cycle (DC) period on whatever chart timeframe its applied to:

************************************

Inputs:
Price ((H+L)/2);

Vars:
Smooth(0),
Detrender(0),
I1(0),
Q1(0),
JI(0),
JQ(0),
I2(0),
Q2(0),
Re(0),
Im(0),
Period(0),
SmoothPeriod(0);

If Currentbar > 5 then begin
Smooth = (4*Price+3*Price[1]+2*Price[2]+Price[3])/10;
Detrender=(0.0962*smooth+0.5769*smooth[2]-0.5769*smooth[4]-0.0962*smooth[6])*(0.075*Period[1]+0.54);

{compute inphase and quadrature components}

Q1 = (0.0962*Detrender + 0.5769*Detrender[2] - 0.5769*Detrender[4] - 0.0962*Detrender[6])*(0.075*Period[1] + 0.54);
I1 = Detrender[3];

{advance the phase of I1 and Q1 by 90 degrees}
JI = (0.0962*I1 + 0.5769*I1[2] - 0.5769*I1[4] -
0.0962*I1[6])*(0.075*period[1] + 0.54);
JQ = (0.0962*Q1 + 0.5769*Q1[2] - 0.5769*Q1[4] -
0.0962*Q1[6]) * (0.075*Period[1] + 0.54);

{phasor addition for 3 bar averaging}
I2 = I1 - JQ;
Q2 = Q1 + JI;

{smooth the I and Q components before applying}
I2 = 0.2*I2 + 0.8*I2[1];
Q2 = 0.2*Q2 + 0.8*Q2[1];

{homodyne Discriminator}
Re = I2*I2[1] + Q2*Q2[1];
Im = I2*Q2[1] - Q2*I2[1];
Re = 0.2*Re + 0.8*Re[1];
Im = 0.2*Im + 0.8*Im[1];
If Im <> 0 and Re <> 0 then Period =
360/ArcTangent(Im/Re);
If Period > 1.5*Period[1] then period =
1.5*Period[1];
If period < 0.67*Period[1] then Period =
0.67*Period[1];
If Period < 6 then Period = 6;
If Period >50 then Period = 50;
Period = 0.2*Period + 0.8*Period[1];
SmoothPeriod = 0.33*Period + 0.67*SmoothPeriod[1];

Plot1 (SmoothPeriod,"DC");
End;

************************************************

Apologies if this is something everyone already has.

Cheers
Steve

 

[Charlton]

Hi Charlton

I tend to agree with your last comment.

In case this becomes of use later, the following is a working version of code that calculates and plots the current Dominant Cycle (DC) period on whatever chart timeframe its applied to:

************************************

Inputs:
Price ((H+L)/2);

Vars:
Smooth(0),
Detrender(0),
I1(0),
Q1(0),
JI(0),
JQ(0),
I2(0),
Q2(0),
Re(0),
Im(0),
Period(0),
SmoothPeriod(0);

If Currentbar > 5 then begin
Smooth = (4*Price+3*Price[1]+2*Price[2]+Price[3])/10;
Detrender=(0.0962*smooth+0.5769*smooth[2]-0.5769*smooth[4]-0.0962*smooth[6])*(0.075*Period[1]+0.54);

{compute inphase and quadrature components}

Q1 = (0.0962*Detrender + 0.5769*Detrender[2] - 0.5769*Detrender[4] - 0.0962*Detrender[6])*(0.075*Period[1] + 0.54);
I1 = Detrender[3];

{advance the phase of I1 and Q1 by 90 degrees}
JI = (0.0962*I1 + 0.5769*I1[2] - 0.5769*I1[4] -
0.0962*I1[6])*(0.075*period[1] + 0.54);
JQ = (0.0962*Q1 + 0.5769*Q1[2] - 0.5769*Q1[4] -
0.0962*Q1[6]) * (0.075*Period[1] + 0.54);

{phasor addition for 3 bar averaging}
I2 = I1 - JQ;
Q2 = Q1 + JI;

{smooth the I and Q components before applying}
I2 = 0.2*I2 + 0.8*I2[1];
Q2 = 0.2*Q2 + 0.8*Q2[1];

{homodyne Discriminator}
Re = I2*I2[1] + Q2*Q2[1];
Im = I2*Q2[1] - Q2*I2[1];
Re = 0.2*Re + 0.8*Re[1];
Im = 0.2*Im + 0.8*Im[1];
If Im <> 0 and Re <> 0 then Period =
360/ArcTangent(Im/Re);
If Period > 1.5*Period[1] then period =
1.5*Period[1];
If period < 0.67*Period[1] then Period =
0.67*Period[1];
If Period < 6 then Period = 6;
If Period >50 then Period = 50;
Period = 0.2*Period + 0.8*Period[1];
SmoothPeriod = 0.33*Period + 0.67*SmoothPeriod[1];

Plot1 (SmoothPeriod,"DC");
End;

************************************************

Apologies if this is something everyone already has.

Cheers
Steve

It's certainly not code that I have, so much appreciated. I will grab it and take a look.

Thanks

Charlton

 

[lwebb]

Link to Ehlers oscillators at the TradeStation forums:

Oscillators by John Ehlers
https://www.tradestation.com/Discussions/Topic.aspx?Topic_ID=28767&SearchTerm=ehler&txtExactMatch=

Quote:
In his latest book Cybernetic Analysis for Stocks and Futures, John Ehlers created or modified a number of oscillators. He also modified some standard oscillators in his previous book, Rocket Science for Traders.

The oscillators are...

1 - Cyber Cycle
2 - CG Oscillator
3 - Relative Vigor Index (RVI)
4 - Stochastic RSI
5 - Stochastic Cyber Cycle
6 - Stochastic CG
7 - Stochastic RVI
8 - Fisher Cyber Cycle
9 - Fisher CG
10 - Fisher RVI
11 - Adaptive Cyber Cycle
12 - Adaptive CG
13 - Adaptive RVI
14 - Sinewave Indicator
15 - Laguerre RSI
16 - Adaptive RSI
17 - Adaptive Stochastic
18 - Adaptive CCI

... small change to some of these oscillators; specifically John Ehlers uses 'alpha' ... changed these to 'Length' (using the formula alpha=2/(Length+1) ) because it is more intuitive.

Apologies for any duplication with already posted code.

 

[lote_tree]

Advanced Oscillators

The Adaptive Cycle Oscillators meet the following criteria:

1. They have zero lag
2. They measure and adapt to the dominant cycle

It seems that with MLT they could be extremely effective. They all seem to perform as well as each other according to Ehler.

Crossings of the adaptive cycle indicator and the trigger signal represent the buy and sell opportunities identified by these indicators.

I've included another interesting oscillator callled the Sinewave. This indicator goes one step further. In the words of John Ehler:

"Compared to conventional oscillators such as the Stochastic or RSI, the Sinewave Indicator has two major advantages. These are as follows:

1. The Sinewave Indicator anticipates the Cycle Mode turning point rather than waiting for confirmation.

2. The phase does not advance when the market is in a Trend Mode. Therefore the Sinewave Indicator does not tend to give false whipsaw signals when the market is in a Trend Mode."

The LeadSine always crosses the Sine line before the turning point in the cycle, giving advance indication of the cyclic turning point. The amount of advance warning relative to the length of the cycle is less for the shorter cycles.

I hope we can get the entry criteria as close to perfect as humanly possible. We need to beat Iraj's 78% win ratio

Naeem

 

[Charlton]

Link to Ehlers oscillators at the TradeStation forums:

Oscillators by John Ehlers
https://www.tradestation.com/Discussions/Topic.aspx?Topic_ID=28767&SearchTerm=ehler&txtExactMatch=

Quote:
In his latest book Cybernetic Analysis for Stocks and Futures, John Ehlers created or modified a number of oscillators. He also modified some standard oscillators in his previous book, Rocket Science for Traders.

The oscillators are...

1 - Cyber Cycle
2 - CG Oscillator
3 - Relative Vigor Index (RVI)
4 - Stochastic RSI
5 - Stochastic Cyber Cycle
6 - Stochastic CG
7 - Stochastic RVI
8 - Fisher Cyber Cycle
9 - Fisher CG
10 - Fisher RVI
11 - Adaptive Cyber Cycle
12 - Adaptive CG
13 - Adaptive RVI
14 - Sinewave Indicator
15 - Laguerre RSI
16 - Adaptive RSI
17 - Adaptive Stochastic
18 - Adaptive CCI

... small change to some of these oscillators; specifically John Ehlers uses 'alpha' and I have changed these to 'Length' (using the formula alpha=2/(Length+1) ) because it is (or at least I think it is) more intuitive.

Thanks - this is very useful, especially with the code as well. Have you done any evaluation of these oscillators ?

The next step as far as I can see is to evaluate them and to, perhaps pick a few, that we can work with.

I haven't looked closely at them yet, but if they have similar inputs, outputs and buy/sell signals then it should be possible to make them interchangeable within a trading engine

Charlton