Charlton's Programmed Trade Development

[Charlton]

Yesterday Iraj held another all day live trading day/seminar attended by 30+ people and he brought up the subject of Programmed trading. He told us that 100% of his regular trading is automated via Tradestation and that he was hitting 70 - 75% (I think that was the figure) of successful trades. This is an impressive figure IMO for a non-discretionary system and he told us that this was the future of trading. We are all to become Execution Managers (sounds a bit like the French Revolution !!)

Anyway I made the rash promise that I would start a thread and therefore a project to automate the concepts of Grey1's strategy using TS.

The way I intend to approach this is:
(a) Define the requirements, in particular the logic of the strategy in terminology i.e. rules that can be used in coding
(b) Create code in TS
(c) Test and tune code for efficiency and, by this, I really mean low-risk, high probability and minimum drawdown

I think the best way to proceed with this task is using a modular approach. This means initially creating indicators that serve a particular purpose that will form part of the overall strategy.

I am thinking of modules such as:
- automated selection of top 3 and bottom 3 stocks from Iraj N minute
- automated creation of orders with correct position size
- automated adjustment of data compression

The reason for the modular approach is that I can release these are useful bits of code as I go along, so they can be tested, receive comments/suggests and add value to members' trading execution early on.

Initially the output will be in the form of signals only e.g. arrows on charts, columns in radar screen that can be used within manual trading. Ultimately these will be changed to generation of orders.

Eventually the plan will be to bring these modules together into one complete strategy.

Part of the process will involve defining a series of conditions that will need some flexibility, probably via inputs. For example, we all know the ideal setup is for MACCI to be overbought or oversold in all timeframes, so there may be inputs to specify where we just want ideal or less than ideal trades. Similarly we know that MACCI does not necesarily have to turn up or down from the 100% OS/OB lines but it may be valid for it to turn within say 80 -100 %, so these are all variables that need to be considered as part of any coding logic.

I will be inviting comments on these kinds of variables.

This will take some time to evolve and develop, but hopefully the modular approach will bring benefits as we proceed.

I will be working on coding this for TS8.3 and will start next week.

Charlton

 

[evostik]

Hi Charlton

Well done for 'volunteering'. It sounds fantastic.

A couple of initial quick comments, if I may. Firstly, many people here use TS2ki rather than 8.3 - I wonder if this is will be a problem at all? Secondly, I am wondering if MACCI is the 'correct' oscillator to base it on considering what Grey1 was saying yesterday?

As I say, just an initial quick couple of thoughts that come to my head after I just got out of bed and read your post!

Cheers
Steve

 

[Grey1]

Yesterday Iraj held another all day live trading day/seminar attended by 30+ people and he brought up the subject of Programmed trading. He told us that 100% of his regular trading is automated via Tradestation and that he was hitting 70 - 75% (I think that was the figure) of successful trades. This is an impressive figure IMO for a non-discretionary system and he told us that this was the future of trading. We are all to become Execution Managers (sounds a bit like the French Revolution !!)

Anyway I made the rash promise that I would start a thread and therefore a project to automate the concepts of Grey1's strategy using TS.

The way I intend to approach this is:
(a) Define the requirements, in particular the logic of the strategy in terminology i.e. rules that can be used in coding
(b) Create code in TS
(c) Test and tune code for efficiency and, by this, I really mean low-risk, high probability and minimum drawdown

I think the best way to proceed with this task is using a modular approach. This means initially creating indicators that serve a particular purpose that will form part of the overall strategy.

I am thinking of modules such as:
- automated selection of top 3 and bottom 3 stocks from Iraj N minute
- automated creation of orders with correct position size
- automated adjustment of data compression

The reason for the modular approach is that I can release these are useful bits of code as I go along, so they can be tested, receive comments/suggests and add value to members' trading execution early on.

Initially the output will be in the form of signals only e.g. arrows on charts, columns in radar screen that can be used within manual trading. Ultimately these will be changed to generation of orders.

Eventually the plan will be to bring these modules together into one complete strategy.

Part of the process will involve defining a series of conditions that will need some flexibility, probably via inputs. For example, we all know the ideal setup is for MACCI to be overbought or oversold in all timeframes, so there may be inputs to specify where we just want ideal or less than ideal trades. Similarly we know that MACCI does not necesarily have to turn up or down from the 100% OS/OB lines but it may be valid for it to turn within say 80 -100 %, so these are all variables that need to be considered as part of any coding logic.

I will be inviting comments on these kinds of variables.

This will take some time to evolve and develop, but hopefully the modular approach will bring benefits as we proceed.

I will be working on coding this for TS8.3 and will start next week.

Charlton

Can I ask you to start looking for a better OSCILLATOR than MACCI ,, MACCI is not an adaptive OSC and there are far better than MACCI in the market,,

MACCI lags,,, you want an OSC which has least lag hence ahead of other codes.. The difference will be between poor entry and perfect entry

Also ..
you need to have a module which trades the trend ( start and finish of the day ) and a module which trades the consolidation

Grey1

 

[belflan]

may be this Oscillator could be of use?

beflan

 

[evostik]

may be this Oscillator could be of use?

beflan

Hi Belflan

Maybe the CG is indeed a good base for us. From my simple understanding, we need an oscillator which includes the following three attributes; minimal/zero lag, an 'alarm/alert' when it turns and, it is adaptive to the dominant cycle period(?).

Its description says that it meets the first two. If the observation period (currently fixed at 10) is replaced by code that calculates half the dominant cycle period then perhaps the third attribute is met too?

Any thoughts?

Cheers
Steve

 

[belflan]

Hi Belflan

Maybe the CG is indeed a good base for us. From my simple understanding, we need an oscillator which includes the following three attributes; minimal/zero lag, an 'alarm/alert' when it turns and, it is adaptive to the dominant cycle period(?).

Its description says that it meets the first two. If the observation period (currently fixed at 10) is replaced by code that calculates half the dominant cycle period then perhaps the third attribute is met too?

Any thoughts?

Cheers
Steve

I was thinking the same, I've seen a few of Edlers indicators that estimate the dominant cycle with a spectrum type output. Not sure how the spectrum type indicator could output a figure for the other indicator tho. Maybe this is abit too complex?

belflan

 

[evostik]

I was thinking the same, I've seen a few of Edlers indicators that estimate the dominant cycle with a spectrum type output. Not sure how the spectrum type indicator could output a figure for the other indicator tho. Maybe this is abit too complex?

belflan

Hi

I believe there is some code that calculates the Dominant Cycle Period in rea time and its 'output' is an integer value. Homodyne Discriminator is the name that rings a bell with me. I have the code somewhere if we decide that is what is required.

Cheers
Steve

 

[belflan]

Hi

I believe there is some code that calculates the Dominant Cycle Period in rea time and its 'output' is an integer value. Homodyne Discriminator is the name that rings a bell with me. I have the code somewhere if we decide that is what is required.

Cheers
Steve

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

 

[Grey1]

This thread will be a new beginning for our traders ..Time to move on.
Grey1

 

[leovirgo]

It is very encouraging indeed.

 

[pedro01]

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.

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.

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'd like to help out on this but I am missing out on a few tricks of the trade I think.

Cheers

Pete

 

[pedro01]

Can I ask you to start looking for a better OSCILLATOR than MACCI ,, MACCI is not an adaptive OSC and there are far better than MACCI in the market,,

MACCI lags,,, you want an OSC which has least lag hence ahead of other codes.. The difference will be between poor entry and perfect entry

Also ..
you need to have a module which trades the trend ( start and finish of the day ) and a module which trades the consolidation

Grey1

Iraj - as per my prior post - we should do this so that the actual oscillator we end up using can be plugged in.

I saw that the oscillators on the site you mentioned in the seminar are available for $195.

I'd be more than happy to buy these & contribute them to the project. The proviso would be that we create the code in such a way that any of the oscillators could be plugged in.

 

[Trader333]

I saw that the oscillators on the site you mentioned in the seminar are available for $195.

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

I think the specific oscillator we use is irrelevant

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


Paul

 

[belflan]

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

yep, it was Ehlers site, Grey stop short of recommending Ehlers site, but did suggest finding a better (more adaptive) indicator than the MACCI.

Codes for Ehlers (more adaptive) Oscillators seem to be all over the net for free

belflan

 

[Tileman]

They are available for free in the Tradestation easy language libary.

Regards
Graham

 

[Grey1]

I donot recommend any company's OSC including MESA and as I said in my seminar I donot really like to plug in or mention some one else's code. Just that there are far better OSC in the market than MACCI

Grey1

 

[evostik]

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.

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.

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'd like to help out on this but I am missing out on a few tricks of the trade I think.

Cheers

Pete

Hi Pete

I believe we could utilise the GLOBALVARIABLE capability to 'capture' the different Oscillator Timeframes that would be needed.

Cheers
Steve

 

[A_B]

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.

We can calculate any N-minute functions and indicators using only 1 minute data. Check Multiply Time Frame MACCI code as an example:

http://www.trade2win.com/boards/technical-trader/29739-tt-toolbox-4.html#post529158

 

[Charlton]

Can I ask you to start looking for a better OSCILLATOR than MACCI ,, MACCI is not an adaptive OSC and there are far better than MACCI in the market,,

MACCI lags,,, you want an OSC which has least lag hence ahead of other codes.. The difference will be between poor entry and perfect entry

Also ..
you need to have a module which trades the trend ( start and finish of the day ) and a module which trades the consolidation

Grey1

Thanks for your advice on indicators and, of course, for sharing your principles of trading with us over the past year. It is up to us now to build our own particular versions of your strategy.

There's a phrase that goes something like - you can give a man a fish to eat for a day or you can teach him to fish for life.

I can see that there is need for different logic for the trending and consolidation phases. There was quite an interesting discussion recently in T2W generated in another thread by a programmer who had to build something to trade the trend, which raised the queston of what is a trend. This highlights the difficulty of coding - any fool can look at a chart and see an up-trend or a down-trend, but it is a lot more difficult describing logical rules that cane be used to define it.

I've just come back from a weekend away, but I see this is generating some interesting discussion already, so Friday's seminar has been very thought-provoking

Charlton

 

[Charlton]

Hi Charlton

Well done for 'volunteering'. It sounds fantastic.

A couple of initial quick comments, if I may. Firstly, many people here use TS2ki rather than 8.3 - I wonder if this is will be a problem at all? Secondly, I am wondering if MACCI is the 'correct' oscillator to base it on considering what Grey1 was saying yesterday?

As I say, just an initial quick couple of thoughts that come to my head after I just got out of bed and read your post!

Cheers
Steve

Steve

There are not generally problems converting TS2ki code into TS8.3 code. In fact often it doesn't need conversion. I don't have TS2ki so I don't know if there are more issues in reverse, but I guess there will always be someone who could make the minor adjustments necessary to code in either direction.

As regards MACCI, Iraj has mentioned in another post and the seminar that there are better oscillators. This is something that members could pursue as a separate topic to see which ones work best under which conditions.

In terms of programmed trading and my suggested modular approach, this is an area that can be refined and developed independently of other modules and is in my view the best way to approach it. It means that different oscillators can be "slotted in" according to changing market conditions, personal preferences or in the light of new knowledge

So it may be that I look at producing some code based on MACCI initially and then swap in Ehlers or whatever.

Charlton