Program Trading: Trade Entry

moreagr · Oct 30, 2008

Thanks Charlton ! I can now use more intuitive values for the global variables.

OK - so now we have an indicator #TT_MTL_CYCLE. This indicator should be put on the 60/30/10/5/6/1 and should be a replacement of your current MACCi indicator as it will plot the cycle on the chart as well as set the global variables.

Code:

// This indicator will return a value based on analyzing the 60 minute $INDU (or other index)
//

Inputs : OBThreshold(100), OSThreshold(-100),CycleLength(6), Smoothing(5), AlertLevelOB(80), AlertLevelOS(-80);

Arrays : CycleHistory[20](0);

Vars : LoopCount(0), Zone(""), Direction(""), RTNVal(0);

// re-arrange the array so that we store the last 30 values of the indicator in case we get more sophisticated 
// in figuring direction

For LoopCount = 2 to 20 Begin
	CycleHistory[LoopCount -1] = CycleHistory[LoopCount];
End;

CycleHistory[20] = TTCycle(CycleLength,Smoothing);

// Now that we have cycle history - we should call another function (TTDirection) that should tell us which way
// The indicator is going - we'll pass in the array & that function will tell us up, down, flat, etc
// That function can be improved over time

// Direction - Indicates direction
//  + moving up
//  - moving down
//  F flat (should not indicate that it is perfecly flat but within a tolerance - say less than 10% angle)

// Insert Function Call to set direction here !!
// What follows is not final - just a simplification

If CycleHistory[20] > CycleHistory[19] then
	Direction = "+"
	else if CycleHistory[20] < CycleHistory[19] then
		Direction = "-"
else
	Direction = "F";

// Now that we have direction, we can look to see if we are OB, OS (based on inputs above) as well as direction 
// and set 2 global variables for the 60 macci as follows :
// Zone - Indicates where it is
// OB In the Overbrought zone
// OS In the Oversold zone
// MID Between OB & OS

If CycleHistory[20] >= OBThreshold then
	Zone = "OB"   						// Overbrought
	else if CycleHistory[20] <= OSThreshold then
		Zone = "OS"				    // Oversold
else
	Zone = "MID"; 						// Between overbrought & oversold


// Now - set the global variables depending on the interval
// I haven't used global variables before but it appears you can only do numerics ! 
// Bugger - out go my OB, OS, MID setting ideas...

Switch(BarInterval) 
Begin
  Case 60:
    RTNVal = GVSetNamedString("Zone60", Zone);
    RTNVal = GVSetNamedString("Direction60", Direction);
  Case 30:
  	RTNVal = GVSetNamedString("Zone30", Zone);
    RTNVal = GVSetNamedString("Direction30", Direction);
  Case 10:
    RTNVal = GVSetNamedString("Zone10", Zone);
    RTNVal = GVSetNamedString("Direction10", Direction);
  Case 5:
  	RTNVal = GVSetNamedString("Zone5", Zone);
    RTNVal = GVSetNamedString("Direction5", Direction);
  Case 3:
    RTNVal = GVSetNamedString("Zone3", Zone);
    RTNVal = GVSetNamedString("Direction3", Direction);
  Case 1:
  	RTNVal = GVSetNamedString("Zone1", Zone);
    RTNVal = GVSetNamedString("Direction1", Direction);
End;

Plot1(CycleHistory[20], "Cycle"); 
Plot2(OBThreshold,"OverBought"); 
Plot3(OSThreshold,"Oversold"); 
plot4(0,"Zero");
Plot5(AlertLevelOB,"Alert");
Plot6(AlertLevelOS,"Alert");

Then the next one goes on the 1 minute chart. It's a show me. It's called #TT_ENTRYPOINT.

It will get the global variables & plot entry points.

Code:

vars : Zone60(""),Zone30(""), Zone10(""), Zone5(""), Zone3(""), Zone1(""), Direction60(""), Direction30(""),
	Direction10(""), Direction5(""), Direction3(""), Direction1(""), Bias(" "), Trigger(" ");
// Reset the trigger every bar

Trigger = " ";

// Get the global variables
	
Zone60 		= GVGetNamedString("Zone60"," ");
Direction60 = GVGetNamedString("Direction60"," ");
Zone30 		= GVGetNamedString("Zone30"," ");
Direction30 = GVGetNamedString("Direction30"," ");
Zone10 		= GVGetNamedString("Zone10"," ");
Direction10 = GVGetNamedString("Direction10"," ");
Zone5 		= GVGetNamedString("Zone5"," ");
Direction5 	= GVGetNamedString("Direction5"," ");
Zone3 		= GVGetNamedString("Zone3"," ");
Direction3 	= GVGetNamedString("Direction3"," ");
Zone1 		= GVGetNamedString("Zone1"," ");
Direction1 	= GVGetNamedString("Direction1"," ");

// if higher timeframes(60,30,10) are OB or pointing down - short bias
// if higher timeframes(60,30,10) are OS or pointing up - long bias

if (Zone60 = "OB" or Direction60 = "-") 
	and (Zone30 = "OB" or Direction30 = "-") 
	and (Zone10 = "OB" or Direction10 = "-") then
		Bias = "Short"
	else if (Zone60 = "OS" or Direction60 = "+") 
		and (Zone30 = "OS" or Direction30 = "+") 
		and (Zone10 = "OS" or Direction10 = "+") then
		Bias = "Long" else
			Bias = "None";

// Look for entry points on lower timeframes
// OS/OB in either 5/3 + 1 is OK

if bias = "Short" and (Zone5 = "OB" or Zone3 = "OB") and Zone1 = "OB" then
		Trigger = "SellShort";

if bias = "Long" and (Zone5 = "OS" or Zone3 = "OS") and Zone1 = "OS" then
		Trigger = "Buy";

if Trigger = "SellShort" then begin
	Plot1(Low);
	Alert;
end;

if Trigger = "Buy" then begin
	Plot2(High);
	Alert ;
end ;

Issues

1 - I am not sure if the strategy itself is correct - I think it may be too strict. I hope you guys can follow the code and make suggestions. I hope the comments in the code help the non-coders.

2 - I haven't had time to test it as I'm in LA on business & it's really hectic at the moment it does compile & it does paint the cycle correctly (at the moment the cycle it paints is MACCi).

3 - We can do a much better job of direction than just comparing the past 2 values but I just haven't had the time to look into this.

This is the baseline for entry point code - we all need to get involved now to tweak the entry rules. For instance, am I expecting too much for the 5/3 and 1 to be over 100 or under 100 ?

Both ESLs and the function are in the attached .ELD

Hi my friends

you guys are way ahead of me in coding.... this weekend I'll try to go though your code and try to come up with some suggestions to add to you value added research... all you guys posting are working very hard... And I can see that and appreciatte the effort..

its almost at an obsessive level which is good :clap:

Charlton · Oct 30, 2008

pedro01 said:
1 - I am not sure if the strategy itself is correct - I think it may be too strict. I hope you guys can follow the code and make suggestions. I hope the comments in the code help the non-coders.

2 - I haven't had time to test it as I'm in LA on business & it's really hectic at the moment it does compile & it does paint the cycle correctly (at the moment the cycle it paints is MACCi).

3 - We can do a much better job of direction than just comparing the past 2 values but I just haven't had the time to look into this.

This is the baseline for entry point code - we all need to get involved now to tweak the entry rules. For instance, am I expecting too much for the 5/3 and 1 to be over 100 or under 100 ?

Both ESLs and the function are in the attached .ELD

This is great - take it easy in LA now and let the rest of us do some catchup, testing and optimisation. I will run the code through the optimiser and produce some output for review, but I probably won't complete this until the end of the weekend

I think it is useful to run this against MACCI initially for 2 reasons:

(1) Create a benchmark against which we can measure other indicators
(2) To refine the buy/sell logic against a known indicator that we have all been using

I will look at adjusting your points 1 and 3. If I can find it again I came across some code dealing with trends and whether they were in the process of change, which might be adapted for this process

Charlton

pedro01 · Oct 30, 2008

Charlton said:
This is great - take it easy in LA now and let the rest of us do some catchup, testing and optimisation. I will run the code through the optimiser and produce some output for review, but I probably won't complete this until the end of the weekend

I think it is useful to run this against MACCI initially for 2 reasons:

(1) Create a benchmark against which we can measure other indicators
(2) To refine the buy/sell logic against a known indicator that we have all been using

I will look at adjusting your points 1 and 3. If I can find it again I came across some code dealing with trends and whether they were in the process of change, which might be adapted for this process

Charlton

Thanks Charlton. Just one more edit from me.

I had a look today, added some print statements & got the following results:

So - that's with #TT_MTL_CYCLE on all timeframes & #TT_ENTRYPOINT on the 1 min.

Print statements are still there if anyone wants to run it like this.

Latest ESL attached - over to you now Charlton, I won't make any more changes whilst you are looking at it. I DID want to test that what was there was running, I wouldn't be comfortable handing over something I hadn't even done a basic test.

Thanks

Pete

lwebb · Oct 30, 2008

Nice work Pedro. I'll take a look over the weekend (like everybody else!) I'm thinking about capturing the the entry conditions as filters and having the Entry component process these. This should save on repetitive conditional code.

pedro01 · Oct 30, 2008

Thanks

A short bias (but about to turn out I guess) captured just before I went to work....

Interesting stuff...

Charlton · Oct 30, 2008

pedro01 said:
Thanks

A short bias (but about to turn out I guess) captured just before I went to work....

Interesting stuff...

I started running the code in my live system for the last couple of hours and it looks promising. I changed the print statements to output the time so that it is possible to check the results after market close. I need to change the code slighlty because the print statement is outputting on every tick and I really just want to see output on the close of each 1 min bar.

Over the weekend I intend to start back testing on buy/sell signals and optimisation. This is all being done on the MACCI indicator as a baseline and to sort out initial coding issues/enhancements.

I hope to provide some output following or during tomorrows live session

Charlton

Charlton · Oct 31, 2008

Charlton said:
I started running the code in my live system for the last couple of hours and it looks promising. I changed the print statements to output the time so that it is possible to check the results after market close. I need to change the code slighlty because the print statement is outputting on every tick and I really just want to see output on the close of each 1 min bar.

Over the weekend I intend to start back testing on buy/sell signals and optimisation. This is all being done on the MACCI indicator as a baseline and to sort out initial coding issues/enhancements.

I hope to provide some output following or during tomorrows live session

Charlton

Attached is the print log for the whole of today's session part from about the first hour. This can act as a baseline prior to any refinement. The times given are Exchange times.

Charlton

pedro01 · Oct 31, 2008

I was watching it too this morning - it definitely needs some refinement on flat.

I was thinking perhaps another input for % change for flat. For example, if the indicator only moves 5% of the total range (diff between OB & OS) then it's flat. Alternatively, we could have an input for total value change in the indicator to consider it flat.

I also added in the Trigger to the print statement on my version...

Code:

Print(Time, " Zone 60 = ", Zone60, ", Direction 60 = ",	Direction60,
	", Zone 30 = ", Zone30, ", Direction 30 = ", Direction30,
	", Zone 10 = ", Zone10, ", Direction 10 = ", Direction10,
	", Zone 5 = ", Zone5, ", Direction 5 = ", Direction5,
	", Zone 3 = ", Zone3, ", Direction 3 = ", Direction3,
	", Zone 1 = ", Zone1, ", Direction 1 = ", Direction1,
	", Bias = ", Bias, ", Trigger = ", Trigger);

Looking forward to seeing what you come up with Charlton...

twistedheat · Nov 1, 2008

pedro01 said:
I was watching it too this morning - it definitely needs some refinement on flat.

I was thinking perhaps another input for % change for flat. For example, if the indicator only moves 5% of the total range (diff between OB & OS) then it's flat. Alternatively, we could have an input for total value change in the indicator to consider it flat.

I also added in the Trigger to the print statement on my version...

Code:

Print(Time, " Zone 60 = ", Zone60, ", Direction 60 = ", Direction60, ", Zone 30 = ", Zone30, ", Direction 30 = ", Direction30, ", Zone 10 = ", Zone10, ", Direction 10 = ", Direction10, ", Zone 5 = ", Zone5, ", Direction 5 = ", Direction5, ", Zone 3 = ", Zone3, ", Direction 3 = ", Direction3, ", Zone 1 = ", Zone1, ", Direction 1 = ", Direction1, ", Bias = ", Bias, ", Trigger = ", Trigger);

Looking forward to seeing what you come up with Charlton...

Hey guys, new to TT and more specifically trading itself - so please take my ideas with a pinch of salt.

Just watched one of Grey1's seminars (wow) and thought I'd pitch in. This post reminded me of something that may, or may not, be of importance. That is "the angle of entry".

By definition, a trend (or correction in lower time frames) is a series of continuous lower lows or higher highs on "bar close" - which in our case of the MACCI (or any other Oscillator used) would be a series of continous lower/higher numbers in a particular direction.

The problem lies with how our eyes, as a collective, define the start of a trend down or trend up on an oscillator. For some, a movement from -88 to -85 would signal an upturn whereas otheres would wait for a "steeper" upturn before they considered it a reversal.

Perhaps those successful with this system could keep an eye on, and log, the point where they were sure of a reversal (logging the value before and after) so the programmers can code in the "angle of attack".

This would also help to define what change in value would constitute as "flatlining".

Charlton · Nov 1, 2008

twistedheat said:
Hey guys, new to TT and more specifically trading itself - so please take my ideas with a pinch of salt.

Just watched one of Grey1's seminars (wow) and thought I'd pitch in. This post reminded me of something that may, or may not, be of importance. That is "the angle of entry".

By definition, a trend (or correction in lower time frames) is a series of continuous lower lows or higher highs on "bar close" - which in our case of the MACCI (or any other Oscillator used) would be a series of continous lower/higher numbers in a particular direction.

The problem lies with how our eyes, as a collective, define the start of a trend down or trend up on an oscillator. For some, a movement from -88 to -85 would signal an upturn whereas otheres would wait for a "steeper" upturn before they considered it a reversal.

Perhaps those successful with this system could keep an eye on, and log, the point where they were sure of a reversal (logging the value before and after) so the programmers can code in the "angle of attack".

This would also help to define what change in value would constitute as "flatlining".

Twistedheat

Welcome - I think you are right. We should monitor the rate of change of the indicator over a period of time. For example with MACCI you can often see it exit OB or OS and then more or less flatten following virtually in parallel the OB/OS line it has just left. Very often when this happens it turns and recrosses. By monitoring progress towards our next target area might inform us about exits or whether the indicator will turn before it gets to OB/OS zones.

We need to also think about associating the entry signals with position size, which would mean a qualitative evaluation of the entry signals. For example - an ideal entry with all TFs in line would use the full calculated position size, whereas a less than ideal entry may also be allowed but using 50% position size.

Furthermore, as Iraj said in an earlier post, we need to evaluate whether a market is trending or not. To some extent the current code does that, but we would also need to look at daily and weekly TFs to establish the general background. This would inform us about the general approach to take on a trading day i.e. are we looking primarily to buy strong stocks or primarily to short weak ones.

The optimiser in TS enables you to automatically work out the best values for inputs. It will take many attempts with this to gradually optimise the various inputs, running it with weak stocks, strong stocks, on trending up days, trending down days, consolidation etc to determine the inputs required together with the most appropriate defaults.

Rate of change of indicator value would be one of the adjustments to the code that we could add in as well. What we have to be careful about during testing is only change 1 input at a time to measure its effect.

Thanks for the suggestion

Charlton

Charlton · Nov 3, 2008

pedro01 said:
Quick update....

On #TT_MTL_CYCLE there's a new input "FlatPercentage(5)"

That means if there's no more than 5% change in value of the indicator, it will return flat. 5% seems to be about right but can be changed on the input.

Then we figure flat amount...

Code:

// If FlatAmt hasn't been calculated yet - do that now... If FlatAmt = 0 then FlatAmt = ((OBThreshold - OSThreshold) / 100) * FlatPercentage;

and when calculating direction

Code:

// Insert Function Call to set direction here !! // What follows is not final - just a simplification If CycleHistory[20] > CycleHistory[19] + FlatAmt then Direction = "+" else if CycleHistory[20] < CycleHistory[19] - FlatAmt then Direction = "-" else Direction = "F";

Any news on the indicator research ?

Pete

Pete

I'm running it live at present and the Flat signal seems to be working quite nicely in radar screen, as are all the other signals. It's a joy to see the signals change from OB/OS/MID and the direction symbols, so the basics are there ready for tuning. I haven't incorporated a buy/sell strategy as yet, because I am still hoping to do that post-session otherwise it is difficult to test different scenarios/input settings without static data.

Charlton

pedro01 · Nov 3, 2008

Quick update....

On #TT_MTL_CYCLE there's a new input "FlatPercentage(5)"

That means if there's no more than 5% change in value of the indicator, it will return flat. 5% seems to be about right but can be changed on the input.

Then we figure flat amount...

Code:

// If FlatAmt hasn't been calculated yet - do that now...	
If FlatAmt = 0 then FlatAmt = ((OBThreshold - OSThreshold) / 100) * FlatPercentage;

and when calculating direction

Code:

// Insert Function Call to set direction here !!
// What follows is not final - just a simplification

If CycleHistory[20] > CycleHistory[19] + FlatAmt then
	Direction = "+"
	else if CycleHistory[20] < CycleHistory[19] - FlatAmt then
		Direction = "-"
else
	Direction = "F";

Any news on the indicator research ?

Pete

pedro01 · Nov 3, 2008

Charlton - how did you manage to reply to my post before I posted it ??? :clap:

That's just spooky...

Flat did work quite well - I tried 10% but that was too much, then 5% was OK so I didn't attempt to tune it further

Charlton · Nov 3, 2008

pedro01 said:
Charlton - how did you manage to reply to my post before I posted it ??? :clap:

That's just spooky...

Flat did work quite well - I tried 10% but that was too much, then 5% was OK so I didn't attempt to tune it further

I replied to it in net present time

Charlton

pedro01 · Nov 3, 2008

Charlton said:
I replied to it in net present time

Charlton

Danger - nerd gag !

Charlton · Nov 4, 2008

pedro01 said:
Danger - nerd gag !

Pete

If the issue with global variables and back-testing proves insurmountable or, if we wish to minimise the use of global variables, then we may be able to do all the calculations on a 1 min chart and mimic the data compression for higher timeframes by calculating the indicator from scratch using the High, low and close prices from the relevant bars.

This will make the coding more complex.

For each 1 minute bar we would probably hold the calculated values in an array. Let’s look at an example. This one is calculating the CCI at the 10 min timeframe, but holding the data at the 1 min timeframe.

The calculation will be based on

• Description: The CCI is the difference between the typical price and the simple moving average of the typical price, divided by the standard deviation of the typical price multiplied by the scaling factor.
• Calculation:
TP = ((H + L + C) / 3)
TPSMA = ((TP1 + TP2 + TP3 + TP4 + ... + TPn) / n)
SD = ((ABS(TP1 - TPSMA) + ... + ABS(TPn - TPSMA)) / n)

CCI = (TPn - TPSMAn) / (SD * 0.015)

First we read in each minute the H, L and C prices for the bar. (cols B to D).

For the 10 min calculation we would check current time and if it coincides with 10 mins i.e. 9:40, 9:50, 10:00 we start a loop that looks back over ten 1 minute bars. It looks for the highest H price over the ten bars, the lowest L price and the Close price at the end of the current bar. It then calculates the components that make up the indicator and the result is shown in column I. and would be held in a variable called 10_min_cci.

When the current time does not coincide with a 10 min interval it looks back to the last completed 10 min interval prior to current time and sets 10_min_cci on the 1 min chart to that value.

The same kind of calculation takes place for each of the timeframes.

The result then is that every single 1 min bar will have a separate 60 min indicator value, 30 min, 10 min, 5 min, 3 min and 1 min. These would be held in an array probably where the rows represent 1 min time intervals and the columns represent the indicator for each TF. There might also be a variable holding the bar number at the higher TF (column K in my example).

Thus at each minute we can calculate the zone and the direction at each and every timeframe.

Charlton

pedro01 · Nov 4, 2008

Good point Charlton.

There's always a way - I guess we need to choose a cycle & see what kind of data we need for it and then move forward.

In the meantime, I'll start looking too for ways to get this stuff to execute chronologically. :smart:

pedro01 · Nov 4, 2008

pedro01 said:
Good point Charlton.

There's always a way - I guess we need to choose a cycle & see what kind of data we need for it and then move forward.

In the meantime, I'll start looking too for ways to get this stuff to execute chronologically. :smart:

Some potential solutions :

ADE
- https://www.tradestation.com/Discussions/Topic.aspx?Topic_ID=33398
- https://www.tradestation.com/wiki/pages/viewpage.action?pageId=8975
- https://www.tradestation.com/Discussions/Topic.aspx?Topic_ID=45709

Multiple $INDU timeframes on 1chart
- https://www.tradestation.com/Discussions/Topic.aspx?Topic_ID=74853
- https://www.tradestation.com/Discussions/Topic_Archive.aspx?Topic_ID=32085

I personally like all time frames on one chart - I will play with that tonight.

That will just let us back test the entry point, not the whole strategy - but if we can backtest the calls on the $INDU moves - that's half the battle.

pedro01 · Nov 4, 2008

I just tried multi-time frames on my PC - but I was off line. Looked like there may be hope in it though...

Import the ELD and then open the workspace - obviously we'd hide the charts & remove the plots when doing it for real.

The ESL is simply a merge of TT_MTL_CYCLE & TT_ENTRYPOINT which gets applied to 6 $NDU charts in 1 chart window.

I'll test this out when I get back to the hotel tonight...

Charlton · Nov 4, 2008

Looking hopeful

pedro01 said:
I just tried multi-time frames on my PC - but I was off line. Looked like there may be hope in it though...

Import the ELD and then open the workspace - obviously we'd hide the charts & remove the plots when doing it for real.

The ESL is simply a merge of TT_MTL_CYCLE & TT_ENTRYPOINT which gets applied to 6 $NDU charts in 1 chart window.

I'll test this out when I get back to the hotel tonight...

This is how I did it before, but on a simpler 2 TF setup. On that occasion it also seemed to work ok in backtesting.

Running your code live now appears to give the right results for the zone in different timeframes (using a print statement in the 1 min chart).

I will need to check it again after market hours to see if it still gives the same results. If it does then we are ok for back testing and I can write the strategy to complete the end to end process

Charlton

Program Trading: Trade Entry

Active member

Experienced member

Guest

Attachments

Member

Guest

Attachments

Experienced member

Experienced member

Attachments

Guest

Junior member

Experienced member

Experienced member

Attachments

Guest

Attachments

Guest

Experienced member

Guest

Experienced member

Attachments

Guest

Guest

Guest

Attachments

Experienced member

Similar threads