Program Trading: Trade Entry

[Charlton]

Ah, I call it an ELS

If you have 6 indicators in separate Radars, each putting a value into a different GV, you can run this after hours and see what all the values and associated times are.
If you want to test the receiving code which reads in the GV's then I agree you have to do it during market hours, because the historical GV's are not 'stored', so you will only get the last GV values after hours.
However you could load the historically generated GV's into an array and then use that for testing the (slightly modified) receiving code.

Glenn

Glenn

You've hit on the issue here. The way we have set things up is to have separate "modules" with GVs passing data between them. One is the cycle analysis and one is is the basket selection and position sizing. A third will be the strategy that takes the GVs to process into buy/short orders, exit orders and stoploss. In order to evaluate different scenarios from start to finish, we wanted to run the TS trader manager analysis and optimsation reports. Ideally during initial development this would be done out of hours, because we can quickly alter and change code/inputs to see the effect.

Later when we are closer to a tuned product then it will be run in live mode during market hours.

I agree with your point about backtesting. I'm not a great fan of it due to market changes and, as you righly say, for Iraj's strategy non-technical days will screw things up. In that respect I would say that backtesting is primarily for bug-testing or will be limited to days where we think they have been behaving technically.

The idea about using an array to store historical values could be handy for example to test the order execution module.

Charlton

 

[Glenn]

Glenn

You've hit on the issue here. The way we have set things up is to have separate "modules" with GVs passing data between them. One is the cycle analysis and one is is the basket selection and position sizing. A third will be the strategy that takes the GVs to process into buy/short orders, exit orders and stoploss. In order to evaluate different scenarios from start to finish, we wanted to run the TS trader manager analysis and optimsation reports. Ideally during initial development this would be done out of hours, because we can quickly alter and change code/inputs to see the effect.

Later when we are closer to a tuned product then it will be run in live mode during market hours.

I agree with your point about backtesting. I'm not a great fan of it due to market changes and, as you righly say, for Iraj's strategy non-technical days will screw things up. In that respect I would say that backtesting is primarily for bug-testing or will be limited to days where we think they have been behaving technically.

The idea about using an array to store historical values could be handy for example to test the order execution module.

Charlton

Charlton
I'm a bit late to the party here. I'll try to catch up.

You mention optimisition reports, which involves backtesting.
(Great for software vendors and no-one else imo).
Any tuned parameters will have no meaning in the future, they are just a tuned retro-fit which happen to produce nice results from past data. Been there, done that.

I think that if you just use a good indicator then that will work fine with mtf's.

Don't want to tread on anyones toes, just trying to help from past experience. :|
Glenn

 

[pedro01]

Ah, I call it an ELS

If you have 6 indicators in separate Radars, each putting a value into a different GV, you can run this after hours and see what all the values and associated times are.
If you want to test the receiving code which reads in the GV's then I agree you have to do it during market hours, because the historical GV's are not 'stored', so you will only get the last GV values after hours.
However you could load the historically generated GV's into an array and then use that for testing the (slightly modified) receiving code.

Glenn

I must be dyslexic !

No idea where I got ESL from ! "English as a Second Language" Perhaps ?

 

[pedro01]

Charlton
I'm a bit late to the party here. I'll try to catch up.

You mention optimisition reports, which involves backtesting.
(Great for software vendors and no-one else imo).
Any tuned parameters will have no meaning in the future, they are just a tuned retro-fit which happen to produce nice results from past data. Been there, done that.

I think that if you just use a good indicator then that will work fine with mtf's.

Don't want to tread on anyones toes, just trying to help from past experience. :|
Glenn

Late to the party ? Someone fetch that man a double.

If you look in the thread http://www.trade2win.com/boards/tec...gram-trading-strong-weak-stock-selection.html you will see the other side of the strategy in development.

That sets up a list of global variables of indicators by 'strength' (although we haven't evaluated what to use for 'strength yet). Then at trade entry time, we'll load these global variables into an array & sort them to determine what to buy/sell. That's effectively what this thread is about - that entry point.

Latest code is here : http://www.trade2win.com/boards/technical-trader/43036-program-trading-trade-entry-4.html#post554960

That has the TT_SET_ARRAY & TT_GET_ARRAY we use for storing the radar list & then getting it back into an array to sort by strength.

Now - in terms of backtesting, I agree we don't want to do a lot of it. For now, we need to get this entry point ELS to make good calls on the $INDU - which it doesn't. Once we have done that, we can then put in the buy/sell logic & trade management.

I am reading up on Ehlers work right now. From what I have read, it may be that one of his indicators may give us a better trigger point but that MACCi may still be OK for direction at the higher timeframes.

So - as this doesn't make good calls, we need to figure out.

- indicator to use
- re-evaluate logic for bias
- re-evaluate logic for entry

This whole set of code is merely intended to be the framework for the strategy. We have that framework & now we need to make it smart. We can change the 3 above elements very simply now that the framework is there.

I actually prefer the earlier version of this entry point ELS that used the global vars but as we can't plug in a different indicator/bias logic/entry logic & retest it, it makes the development cycle much longer as we have to wait for the next day.

 

[Charlton]

Charlton
I'm a bit late to the party here. I'll try to catch up.

You mention optimisition reports, which involves backtesting.
(Great for software vendors and no-one else imo).
Any tuned parameters will have no meaning in the future, they are just a tuned retro-fit which happen to produce nice results from past data. Been there, done that.

I think that if you just use a good indicator then that will work fine with mtf's.

Don't want to tread on anyones toes, just trying to help from past experience. :|
Glenn

Glenn

First - you are not treading on anyone's toes and I your past experience will be very useful here.

As I said I am not a big fan of backtesting and would not be looking at going back too far for the reasons you state.

However, the aim of this project is to generate trades with a reasonable to high probability of a successful outcome and to allow sufficient flexibility in the solution to cater for changing market conditions.

A computer program requires some kind of logic to make trading decisions. Let's take a simple case - the market is generally trending down on a particular day and you want the program to generate short sell signals. We know from our sesssions with Iraj that we would like the 10 min MACCI to be in overbought territory and heading downNow the first part is easy to compute - MACC is above 100. The second part is less clear - heading down could be simply previous value greater than current value, but would it be better to have 2 previous values heading down. How do we know ?

We also know that a reasonable short sell might occur if MACCI turns below 100. Is 90 to 100 a zone where this might occur and generate a sell short ? What about 85 to 100 ? Could we go as low as 65 or would that be risking it too much ?

These kinds of decisions/rules need to be set, especially with relatively unsophisticated software like TS running on unsophisticated hardware like a home pc. The only way we can decide on the rules is from past experience. Even if you set the rules and see how they perform live, this has still effectively become back-tested once the session is complete.

I just don't see how you can set up any kind of rule/decision without calling on some previous experience. Even the use of MACCI itself is doing that, because we have had experience in the past that it kinda works.

Charlton

 

[pedro01]

Actually - this is best for latest version of ELS files...

 

[pedro01]

Actually - this is best for latest version of ELS files...

So - what are the suggestions for this entry point logic ?

We have - OB/OS area (+100, -100).
We have 'alert area' = (+80, -80)
We have direction.

Some thoughts (let's consider buy rules, reverse for sell)

BIAS
- If the direction is up but we are above the alert area, then we shouldn't take a long.
- If the direction is flat & we are below the alert area, should we bias long or wait for the turn up ?
- Do we always need the backup of all 3 ? If not, which specific scenarios should we consider ?

Entry
- do we need to look for any specific candle formation on the 1 min ?
- can we say OK for a timeframe if it turns up, even if it's between the alert zones ?
- can we say OK for a timeframe if it is flat & below the lower alert zone ?
- do we need backup of all 3 lower time frames ? if not, which specific scenarios should we consider ?
- do we need to consider VIX ? Is VIX even applicable at 1 min timeframes ?

 

[Glenn]

Late to the party ? Someone fetch that man a double.

If you look in the thread http://www.trade2win.com/boards/tec...gram-trading-strong-weak-stock-selection.html you will see the other side of the strategy in development.

That sets up a list of global variables of indicators by 'strength' (although we haven't evaluated what to use for 'strength yet). Then at trade entry time, we'll load these global variables into an array & sort them to determine what to buy/sell. That's effectively what this thread is about - that entry point.

Latest code is here : http://www.trade2win.com/boards/technical-trader/43036-program-trading-trade-entry-4.html#post554960

That has the TT_SET_ARRAY & TT_GET_ARRAY we use for storing the radar list & then getting it back into an array to sort by strength.

Now - in terms of backtesting, I agree we don't want to do a lot of it. For now, we need to get this entry point ELS to make good calls on the $INDU - which it doesn't. Once we have done that, we can then put in the buy/sell logic & trade management.

I am reading up on Ehlers work right now. From what I have read, it may be that one of his indicators may give us a better trigger point but that MACCi may still be OK for direction at the higher timeframes.

So - as this doesn't make good calls, we need to figure out.

- indicator to use
- re-evaluate logic for bias
- re-evaluate logic for entry

This whole set of code is merely intended to be the framework for the strategy. We have that framework & now we need to make it smart. We can change the 3 above elements very simply now that the framework is there.

I actually prefer the earlier version of this entry point ELS that used the global vars but as we can't plug in a different indicator/bias logic/entry logic & retest it, it makes the development cycle much longer as we have to wait for the next day.

Thanks yes I can see your overall dev plan and it looks good to me.
One thing I haven't spotted yet is whether you check the fills compared to the orders, because if the fills are different it will screw up your exit sizes etc.

Glenn

 

[Charlton]

Thanks yes I can see your overall dev plan and it looks good to me.
One thing I haven't spotted yet is whether you check the fills compared to the orders, because if the fills are different it will screw up your exit sizes etc.

Glenn

Glenn

The order execution hasn't been tackled as yet. What I was planning to do here was to read the position size, which we would have to do for example to take 75% off the table. You make a good point here - for example, what do we do if we have generated an order for 100 shares and the fill is delayed and conditions change. So we may need to compare orders to fills so we cancel any outstanding orders.

Thanks

Charlton

 

[Glenn]

Suggestions:-
1. Use the macci + 3 sma of it for crossover signals, if only for testing. Avoids many of the issues you describe and gives good signals.
2. If the 10 + 30 min or the 10 + 60 min are in agreement then take that as the market direction.
If the 1 + 3 minute or 1 + 5 minute are in agreement with the above, then take that as the entry signal.
3.
BIAS- If the direction is up but we are above the alert area, then we shouldn't take a long. Agreed

- If the direction is flat & we are below the alert area, should we bias long or wait for the turn up ?
Depends if you stick with a single line or use a signal line. If the former then Yes

- Do we always need the backup of all 3 ? If not, which specific scenarios should we consider ?
See 2. above.

Entry- do we need to look for any specific candle formation on the 1 min ? NO

- can we say OK for a timeframe if it turns up, even if it's between the alert zones ? YES

- can we say OK for a timeframe if it is flat & below the lower alert zone ? Don't inderstand this question.

- do we need backup of all 3 lower time frames ? if not, which specific scenarios should we consider ? See 2. above.

- do we need to consider VIX ? Is VIX even applicable at 1 min timeframes ? Imho, NO.


Glenn

 

[Charlton]

Suggestions:-
1. Use the macci + 3 sma of it for crossover signals, if only for testing. Avoids many of the issues you describe and gives good signals.

Thanks - what you say here has really confirmed in my mind the wisdom of going for some of the Ehler indicators. Lote_Tree has been investigating this I believe

2. If the 10 + 30 min or the 10 + 60 min are in agreement then take that as the market direction.
If the 1 + 3 minute or 1 + 5 minute are in agreement with the above, then take that as the entry signal.

Again - this is useful because I think it simplifies some of what we were doing

3.
BIAS- If the direction is up but we are above the alert area, then we shouldn't take a long. Agreed

- If the direction is flat & we are below the alert area, should we bias long or wait for the turn up ?
Depends if you stick with a single line or use a signal line. If the former then Yes

- Do we always need the backup of all 3 ? If not, which specific scenarios should we consider ?
See 2. above.

Entry- do we need to look for any specific candle formation on the 1 min ? NO


- can we say OK for a timeframe if it turns up, even if it's between the alert zones ? YES

This last point I would like some clarification on - taking MACCI as the example, if it turned up at say 75 i.e. between the 2 suggested alert zones, would this give sufficient room for an adequate run for a buy signal ? If we do issue a buy signal at this point, should we reduce position size on the basis that it doesn't have far to run before a reversal of the cycle might take place ?

- can we say OK for a timeframe if it is flat & below the lower alert zone ? Don't inderstand this question.

- do we need backup of all 3 lower time frames ? if not, which specific scenarios should we consider ? See 2. above.

- do we need to consider VIX ? Is VIX even applicable at 1 min timeframes ? Imho, NO.


Glenn

I've added a few comments and a question that would help us

Thanks

Charlton

 

[pedro01]

Suggestions:-
1. Use the macci + 3 sma of it for crossover signals, if only for testing. Avoids many of the issues you describe and gives good signals.
2. If the 10 + 30 min or the 10 + 60 min are in agreement then take that as the market direction.
If the 1 + 3 minute or 1 + 5 minute are in agreement with the above, then take that as the entry signal.
3.
BIAS- If the direction is up but we are above the alert area, then we shouldn't take a long. Agreed

- If the direction is flat & we are below the alert area, should we bias long or wait for the turn up ?
Depends if you stick with a single line or use a signal line. If the former then Yes

- Do we always need the backup of all 3 ? If not, which specific scenarios should we consider ?
See 2. above.

Entry- do we need to look for any specific candle formation on the 1 min ? NO

- can we say OK for a timeframe if it turns up, even if it's between the alert zones ? YES

- can we say OK for a timeframe if it is flat & below the lower alert zone ? Don't inderstand this question.

- do we need backup of all 3 lower time frames ? if not, which specific scenarios should we consider ? See 2. above.

- do we need to consider VIX ? Is VIX even applicable at 1 min timeframes ? Imho, NO.


Glenn

Thanks Glenn - for the 1 question I didn't explain well....

if the signals are long, the indicator is between the lower alert zone & OS, then can we take that as a long signal ?

My guess would be yes.

 

[Glenn]

This last point I would like some clarification on - taking MACCI as the example, if it turned up at say 75 i.e. between the 2 suggested alert zones, would this give sufficient room for an adequate run for a buy signal ? If we do issue a buy signal at this point, should we reduce position size on the basis that it doesn't have far to run before a reversal of the cycle might take place ?

The length of time left for an 'adequate' run depends on which timeframe you are looking at and more particularly which timeframe you are trading.
Certainly you would want some headroom in the 3 higher timeframes but if the engine is only scalping say 20c, then 75 is ok imho even in the 10 min t/f.
As for the lower timeframes (1.3.5) I think it doesn't matter whether you are near the alert zone or not so long as you are getting a proper signal to enter.
However you could make the engine 'safer' to use by only giving signals when there is plenty of headroom all round.

Reduce position size when you trade against the trend or when the volatility gets high.

Glenn

 

[Glenn]

Thanks Glenn - for the 1 question I didn't explain well....

if the signals are long, the indicator is between the lower alert zone & OS, then can we take that as a long signal ?

My guess would be yes.

Agreed, an ideal place to catch a good run up.

Glenn

 

[pedro01]

I think I've made the changes necessary, although not much testing yet as I have to go out & play pool tonight and drink enough beer to make my 6am run torture...

One thing that completely went above my head was

"Use the macci + 3 sma of it for crossover signals" - can someone explain, please ?

So that's not in the code. What is in :

- new setting for zone = AB - alert zone buy, AS alert zone sell (should be optional)
- The code has shrunk through more use of functions (bias, trigger, direction)
- in the AB alert zone, flat and down pointing will be short bias
- in the AB alert zone, pointing up will not be long bias
- look for 10 & 30 or 10 & 60 to agree for bias
- still only looking at OB/OS in the smaller timeframes
- look for 5 & 1 or 3 & 1 to agree for smaller timeframes

This is just the #TT_MTL_CYCLE3 indicator inluded here & the related functions.

If you look at the Buy & Sell signals generated by this over the past 30 days - look at the 1 min chart relating to the stated entry points, we are certainly moving towards something more interesting now !

- any comments would be appreciated.

 

[Glenn]

"Use the macci + 3 sma of it for crossover signals" - can someone explain, please ?

Pete

See pic attached.
Green line is the Macci. Red line is a 3 sma of the Macci.
When the red line crosses over the green line you get a signal.

Reason it's suggested is that it works well enough, is a bit more adaptive, signals are clear, no need to look for flatness or turning points, similar to many of the Ehler's (which use crossovers), hence useful for basic and comparative testing imho.

Does that explain it ok ?
Didn't mean to interrupt the excellent work you are doing.
It's just an idea.

Glenn

 

[Glenn]

- in the AB alert zone, pointing up will not be long bias

Pete

Maybe it's too early in the day - don't understand this.
If you are in the right zone for giving a buy signal, why ignore a buy signal ?

I can't read your ELD. Is that a TS8 format ?

Glenn

 

[twistedheat]

Pete

Maybe it's too early in the day - don't understand this.
If you are in the right zone for giving a buy signal, why ignore a buy signal ?

I can't read your ELD. Is that a TS8 format ?

Glenn

I think he meant that in the "Alert Sell" zone (which would be the "overbought" zone in MACCI) you would not take the sell signal if the MACCI was still in an upward direction.

Vice-versa for the "Alert Buy" zone.

 

[Trader333]

Many of us are still using TS2000i which means that we cannot read any ELD files that are posted. Is it possible to post the code in text as well ?


Paul

 

[lote_tree]

I'm also using TS2Ki and can't touch the juicy cakes in the window

Are there any resources available to help coders translate TS8.3 code when coding for TS2000i? I.e Descriptions of reserved word differences and possible work arounds etc?

Naeem