Charlton's Programmed Trade Development

[Charlton]

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

Great - more useful stuff. I think we need a sub-group to examine the pros and cons of each of the adaptive oscillators suggested so far and to run them through TS. It would be best to create some TS strategies so that we can use the TradeManager analysis reports to provide some comparable stats.

I will start to do this against a fixed basket of strong and weak stocks, because I personally want to see these in action and to see what inputs are signals are required.

We can compare notes in due course

Charlton

 

[moreagr]

one suggestion with the elhers indicators that are posted above ... would be to plot a show me or paint bar instead of ploting an indicator pane or panes... this could save our members here some sreen real estate.

 

[pedro01]

OK - let me suggest ESL # 1.

First ESL we need is one that goes on the 60,30,10,5,3,1 minute $INDU

Inputs :
OSArea(-80), OBArea(80); // because different oscillators will have different OS/OB zones

Pseudo Code :

1 - calculate indicator value // here's where you call your macci or its replacement
2 - analyse the value
-- Here's the tricky part - what info do we need about the value

a) is it in the OB or OS zone
b) is it changing direction
c) is it changind direction out of OB/OS
d) is it flat
e) is it pointing up or down​

3) based on a to e, we set a global var telling us what that timeframe is doing

So - what do we want to know about the oscillator - just OB & OS - or do we want to make it more sophisticated ?

Let's not get into code yet - let's just lay down the requirements - what is it we want to know about the oscillator in the various time frames ? Remember - it may be more important that it's turning than that it's in OS/OB.

Thoughts ?

 

[m_grindy]

Just to let you know I'm super interested in this thread and following the progress, but don't think I'm technical enough really to be of great assistance. I've got a coder who I'm working with to try and code up the same thing who's not a member of this site, so if he has any luck or ideas I'll be sure to post them here. Quite useful to have someone doing it from a completely seperate perspective.

Mike

 

[pedro01]

Just to let you know I'm super interested in this thread and following the progress, but don't think I'm technical enough really to be of great assistance. I've got a coder who I'm working with to try and code up the same thing who's not a member of this site, so if he has any luck or ideas I'll be sure to post them here. Quite useful to have someone doing it from a completely seperate perspective.

Mike

Look at my last post - it's not technical. We need to define this in a non-technical way before coding it. Your ideas are welcome.

 

[lwebb]

OK - let me suggest ESL # 1.

First ESL we need is one that goes on the 60,30,10,5,3,1 minute $INDU

Inputs :
OSArea(-80), OBArea(80); // because different oscillators will have different OS/OB zones

Pseudo Code :

1 - calculate indicator value // here's where you call your macci or its replacement
2 - analyse the value
-- Here's the tricky part - what info do we need about the value

a) is it in the OB or OS zone
b) is it changing direction
c) is it changind direction out of OB/OS
d) is it flat
e) is it pointing up or down​

3) based on a to e, we set a global var telling us what that timeframe is doing

So - what do we want to know about the oscillator - just OB & OS - or do we want to make it more sophisticated ?

Let's not get into code yet - let's just lay down the requirements - what is it we want to know about the oscillator in the various time frames ? Remember - it may be more important that it's turning than that it's in OS/OB.

Thoughts ?

Interesting post pedro01. I'm going to break this out into its own thread, Program Trading: Trade Entry. I'll post more there.

 

[lwebb]

Further to pedro01's post on laying down requirements, I was wondering if it made sense to break this into a couple of areas, for example:

Trade Entry
Trade Management
Trade Exit

 

[Charlton]

Further to pedro01's post on laying down requirements, I was wondering if it made sense to break this into a couple of areas, for example:

Trade Entry
Trade Management
Trade Exit

Agreed - I think we will need several sub-threads to make following this easier. Please can we start all sub-threads with the words "Program Trading:", so it is easier to review it.

Members don't have to be technical, by the way, to contribute. Equally we need evaluation of different oscillators/indicators to fulfil the requirements under the main broad areas above e.g. overbought/oversold conditions (as alternative to MACCI), weak/strong stock selection (as alternative to N min change), testing of any code written and suggestions of improvements e.g. to allow for flexibility of choice so users can if they wish slot in different oscillators within reason

Charlton

 

[pedro01]

Good idea guys.

 

[TheMoneyMachine]

Great thread/idea Charlton, i will contribute where i can.

Regards

TMM

 

[lote_tree]

OK - let me suggest ESL # 1.

First ESL we need is one that goes on the 60,30,10,5,3,1 minute $INDU

Inputs :
OSArea(-80), OBArea(80); // because different oscillators will have different OS/OB zones

Pseudo Code :

1 - calculate indicator value // here's where you call your macci or its replacement
2 - analyse the value
-- Here's the tricky part - what info do we need about the value

a) is it in the OB or OS zone
b) is it changing direction
c) is it changind direction out of OB/OS
d) is it flat
e) is it pointing up or down​

3) based on a to e, we set a global var telling us what that timeframe is doing

So - what do we want to know about the oscillator - just OB & OS - or do we want to make it more sophisticated ?

Let's not get into code yet - let's just lay down the requirements - what is it we want to know about the oscillator in the various time frames ? Remember - it may be more important that it's turning than that it's in OS/OB.

Thoughts ?

Pete,

Great stuff mate. I think we may need to think about what type of mechanical system we're designing. Is it designed to catch minor swings thus morphing into a scalping strategy or are we looking to catch larger swings intraday?

If we're looking at a scalping strategy we can obviously be more liberal with our entry criteria. However, larger swings may require a more stringent criteria such as the Macci or it's equivalent being OB/OS in all TF's.

Also testing these advanced oscillators in multiple timeframes is going to be a challenge in itself, especially if you can't programme. I'm currently tracking the Fisher RVI with great difficulty. The buy and sell signals for this oscillator occurs when the RVI crosses the trigger line above +2 or below -2.

When you're trying to note when the RVI crosses the trigger for 6 different TF's all at once, assessing the effectiveness of the oscillator becomes very difficult. Oscillator's like the Inverse Fisher Cyber Cycle will be easier to assess for non programmers because they act more like the Macci, i.e buy/sell on OB/OS conditions.

Anyone willing to code up the Fisher RVI in a way which makes it easier to test using MLT?

I think we may have the ingredients here to come up with a great system.

Naeem

 

[moreagr]

Naeem,

I have been going through this tread and noticed your topic on volatility stops you used 365 days.. I think it would be better to use tradeable days in the year verus 365.

try using 252 days instead and see if it is better

 

[dcraig1]

Pete,
Also testing these advanced oscillators in multiple timeframes is going to be a challenge in itself, especially if you can't programme. I'm currently tracking the Fisher RVI with great difficulty.
Naeem

Indeed. Probably a LOT more difficult than just overcoming some TS limitations. There may well be no "best" oscillator at all considering the issue of multiple markets and choice of period for the oscillator (s). Add in multiple aggregation preiods (TFs) and there is a lot of degrees of freedom.

In fact I would be surprised if there turned out to be a clear cut winner (though I'd like to be pleasantly surprised).

Methinks that some sort of approach using some sort of optimizer might prove useful. Not because it will spit out a holy grail, but if you can plot an optimization surface, then that might provide some insight into the effectiveness of the thing in question.

 

[Charlton]

Indeed. Probably a LOT more difficult than just overcoming some TS limitations. There may well be no "best" oscillator at all considering the issue of multiple markets and choice of period for the oscillator (s). Add in multiple aggregation preiods (TFs) and there is a lot of degrees of freedom.

In fact I would be surprised if there turned out to be a clear cut winner (though I'd like to be pleasantly surprised).

Methinks that some sort of approach using some sort of optimizer might prove useful. Not because it will spit out a holy grail, but if you can plot an optimization surface, then that might provide some insight into the effectiveness of the thing in question.

I agree - that is why I propose the "modular" approach, whereby each module performs a function and receives input from the previous module and sends output to the next module. So one module would produce, say, entry signals whereas another deals with money management . In this way you could swap in and out of the strategy different oscillators in order to test optimisation.

Charlton

 

[lote_tree]

Naeem,

I have been going through this tread and noticed your topic on volatility stops you used 365 days.. I think it would be better to use tradeable days in the year verus 365.

try using 252 days instead and see if it is better

moreagr,

Most hedge funds use 365 in their trading. You can use 252 if you like. 252 will give you a bit more wiggle room with your stops. However you do need to bear in mind that the VIX is calculated using the 365 day value. Furthermore you might argue why use 390min when the VIX is calulated using the 1440min value? The method of calculation you use is a decision for you based on your style of trading. I personally use the 365 value in my trading.

Indeed. Probably a LOT more difficult than just overcoming some TS limitations. There may well be no "best" oscillator at all considering the issue of multiple markets and choice of period for the oscillator (s). Add in multiple aggregation preiods (TFs) and there is a lot of degrees of freedom.

dcraig1,

You make a great point. I think we need to agree on a general criteria on what we expect from our oscillator. The MLT concept is where the edge kicks in from what I understand so the oscillator doesn't have to be the holy grail. We just need it to be a lot more efficient than the Macci.

Naeem

 

[rjh2000]

Agreed - I think we will need several sub-threads to make following this easier. Please can we start all sub-threads with the words "Program Trading:", so it is easier to review it.

Members don't have to be technical, by the way, to contribute. Equally we need evaluation of different oscillators/indicators to fulfil the requirements under the main broad areas above e.g. overbought/oversold conditions (as alternative to MACCI), weak/strong stock selection (as alternative to N min change), testing of any code written and suggestions of improvements e.g. to allow for flexibility of choice so users can if they wish slot in different oscillators within reason

Charlton

Great thread Charlton, thanks for getting it going. I'm new to TS (just installed TS2Ki last week!) but will try and contribute something once I'm familiar with EasyLanguage etc. Although initially it may be just testing the various modules. BTW I do have 20+years experience in software dev and agree totally with your modular approach

 

[pedro01]

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

I totally agree - it's evaluation that's the key now.

We need a volunteer - I reckon Charlton & I will end up doing most of the coding so....

any volunteers ?

 

[moreagr]

moreagr,

Most hedge funds use 365 in their trading. You can use 252 if you like. 252 will give you a bit more wiggle room with your stops. However you do need to bear in mind that the VIX is calculated using the 365 day value. Furthermore you might argue why use 390min when the VIX is calulated using the 1440min value? The method of calculation you use is a decision for you based on your style of trading. I personally use the 365 value in my trading.



dcraig1,

You make a great point. I think we need to agree on a general criteria on what we expect from our oscillator. The MLT concept is where the edge kicks in from what I understand so the oscillator doesn't have to be the holy grail. We just need it to be a lot more efficient than the Macci.

Naeem

hmm

I did not know that.... I was getting conflicting info I guess. some texts say the hole year while other use tradale days maybe its individual equities that use 252

 

[rjh2000]

I totally agree - it's evaluation that's the key now.

We need a volunteer - I reckon Charlton & I will end up doing most of the coding so....

any volunteers ?

I'll make a start at evaluating them - if I need help I'll let you know.

Ronan

 

[pedro01]

I was not able to attend so was this Ehlers site and if not which site was it ?

The choice of oscillator will be critical to success in my view.

Paul

The site is MESA https://mesasoftware.com/indicators.htm

Of course the choice of oscillator will be critical but in terms of our coding, once we know which oscillator to use, we just plug it in. Not having decided the oscillator does not impede our projects process.

Me being jetlagged & trying to do 2 jobs at once at work will certainly impede out progress though !!