Program Trading: Trade Entry

[options]

Would love to help guys, but I don't use Tradestation so would be as much use to you as a fart in a thunderstorm.

If this sort of thing would run in It finance charts, then I can help out.

Really must look at getting tradestation. May be back in the uk soon anyway.

 

[Glenn]

Glenn,

Will this be primarily on just one instrument such as the YM or ES as you have shown above ?


Paul

Paul
The tests should be run on the INDU data, which is what I was doing on Friday.
i.e. getting signals from the INDU and using them to trade the YM.
Glenn

 

[Glenn]

If your code can beat YM then the odds are by diversification of risk over N stocks you definitely will beat the stock market,, Hence most program trades trade the stocks than futures as the correlation between YM and CASH can be reduced/ increased by choice of stocks and give you a massive edge. (hence iraj N minute )

Agree absolutely.
I was only trading the YM because I'm used to it and didn't have time to manually pick and trade stocks because I was also busy coding.
Glenn

 

[Trader333]

Paul
The tests should be run on the INDU data, which is what I was doing on Friday.
i.e. getting signals from the INDU and using them to trade the YM.
Glenn

Glenn,

OK that is fine and I will help when I can and it suits me (at present) that it is just one instrument. I have tried to follow the discussions on this but I am probably a bit behind now so I will see what I need to use and ask if I need to.

Iraj,

I agree with what you have said and it was only for testing that I asked the question to Glenn.


Paul

 

[wheezergeezer]

It is vital that passive members of TT to also some how participate in this research project and be awarded for it.

You need to have a research leader and also identify who is going to be given a copy of the final product..

I suggest to have a chat amongst yourselves before further development of the code because the code worth a lot of money once finished Please email me with any suggestions you got about the research work ,,

I can arrange a sub forum so that only the member of the research team can post and read the content



let me know

[email protected]

grey1

I'd love to help out but, programming is like trying to read chinese to me. unfortunatly!! but willing to help in any way I can........let me know

 

[Trader333]

Glenn,

Can you clarify which code is to be tested ? I know you have called it MACC-653 mtf and I just want to be clear on exactly which indicator(s) they are.


Paul

 

[Glenn]

Glenn,

Can you clarify which code is to be tested ? I know you have called it MACC-653 mtf and I just want to be clear on exactly which indicator(s) they are.


Paul

Paul
Afaik nothing has been decided about which indicators to test.
Before anything is tested we need to know if we have a testing team or not, how many people, who will test what, when and how. I will then issue some help notes to the team and coordinate the effort.
I'm only the monkey in this, not the organ grinder. I'm assuming that Charlton and Pedro are leading overall so imo there needs to be some kind of 'committee' meeting to agree the way forward and next steps before we go any further.
(Unless I'm misreading the whole situation !)
Glenn

 

[Tantalus]

I'd be willing to help in any way. I'm running TS 8.3 and would be able to test during market hours but I've no coding skill. On an input note (please ignore if irrelevant) I'd just like to pick up a point Iraj is making about correlation and risk. Would it be any use to measure the deviation or spread from the index of the prospective stock? If something like RSI was used to identify levels of high deviation it could serve as another tool to mitigate risk.

 

[A_B]

Afaik nothing has been decided about which indicators to test.
Glenn

I think we should test both MACCI(6,5) and MACC-653 during market hours and print results to the file. After that backtest the same day and compare results with live test.

One remark: not all TT members have TradedeStation account so we have to use different data sources for INDU that can differ.

 

[Trader333]

I already have MLT for Macci using the standard (6, 5 settings) but if I am asked to test CCI with a 3 SMA then I will.


Paul

 

[Charlton]

Paul
Afaik nothing has been decided about which indicators to test.
Before anything is tested we need to know if we have a testing team or not, how many people, who will test what, when and how. I will then issue some help notes to the team and coordinate the effort.
I'm only the monkey in this, not the organ grinder. I'm assuming that Charlton and Pedro are leading overall so imo there needs to be some kind of 'committee' meeting to agree the way forward and next steps before we go any further.
(Unless I'm misreading the whole situation !)
Glenn

Glenn

This sounds like a plan to me. Contrary to rumours that used to circulate on another site there are no monkeys here I am in agreement with the committee idea and that you coordinate testing.

As I see it there are two main categories of testing:
(a) testing code to ensure it functions correctly
(b) testing of strategy and, by this I mean evaluation of indicators for determination of strong/weak stocks. cycle analysis and indentification of OB/OS

We have either the current MACCI or the MACCI 653 version, which we can use for 2 purposes:
(1) as a benchmark to compare other indicators or variations in part of the engine
(2) to provide one "stable" environment against which code can be finished off. It's difficult to complete a first version of code if inputs, outputs, globalvariables etc are changing constantly because different indicators are being tried out

The evaluation of indicators does not necessarily need all of the code. Initially position sizes and baskets of stock can perhaps be fixed for the day. Once some candidate indicators have been found then they can be incorporated into the rest of the code, so we can have these different aspects of testing and code development going on in parallel.

Those are my initial thoughts

Charlton

 

[pedro01]

For this exercise, don't worry if you don't have programming skills. We can help out with that.

What we need is a 'coallition of the willing' - we have a mixture of skills here, so if you think you lack a particular skill, it doesn't stop you from helping.

 

[Glenn]

Glenn

This sounds like a plan to me. Contrary to rumours that used to circulate on another site there are no monkeys here I am in agreement with the committee idea and that you coordinate testing.

As I see it there are two main categories of testing:
(a) testing code to ensure it functions correctly
(b) testing of strategy and, by this I mean evaluation of indicators for determination of strong/weak stocks. cycle analysis and indentification of OB/OS

We have either the current MACCI or the MACCI 653 version, which we can use for 2 purposes:
(1) as a benchmark to compare other indicators or variations in part of the engine
(2) to provide one "stable" environment against which code can be finished off. It's difficult to complete a first version of code if inputs, outputs, globalvariables etc are changing constantly because different indicators are being tried out

The evaluation of indicators does not necessarily need all of the code. Initially position sizes and baskets of stock can perhaps be fixed for the day. Once some candidate indicators have been found then they can be incorporated into the rest of the code, so we can have these different aspects of testing and code development going on in parallel.

Those are my initial thoughts

Charlton

"Contrary to rumours" iii.co.uk ? I remember being accused of moving the market after March 2000 when it all came tumbling down and I was posting target prices which got hit. Never again

Moving on..

I was thinking slightly differently
i.e. that initially all we need to do is test a variety of indicators using INDU data to see which gives the best result. i.e. the earliest Entry signals. At any turning point they will all give a signal at some stage, so the earliest would seem to be the winner.
That could mean 10, 20, 50,100 different indicators, who knows ?
There is no need to run the stock selection (etc) code to do that.
While that is going on the remainder of the code could be in progress in parallel.

However it seems best to run the indicator tests on the same data and the only way to do that is to run them all intraday, ideally on the same day(s) using a number of people to do it.
But if we had 5 people and 20 indicators to test, it would have to be done in 4 batches on 4 different days, with the best indicator being picked from each batch. Then run final set of tests on the 5 best.

Each tester would have two bits of code.
- One SEND bit for their indicator, set up in Radars in 6 timeframes using INDU, each writing to a different GV. As Pedro said, we could help people to code this in part or in full. e.g. The Ehler stuff is already available and would only need a few extra lines of code to drive the testing.
- One RECEIVE bit to GET the GV's from the 6 timeframes, and look for composite signals, and print them in the debug editor. This bit of code would only need to be written once and wouldn't need to be altered, because the same GV names could be used in all of the different SEND code.

Happy to be shot down in flames.

If it's easier to talk about all this rather than type, could use Skype, MSN, Paltalk or YM.

Glenn

 

[Trader333]

Glenn,

Yes I agree, the stock selection is probably the last part of this because we know that we want to Short the weakest and Long the strongest stocks relative to INDU using whatever signal we get from whichever indicator we end up selecting. So in my view the focus for the testing team should now be entirely on which indicator to use.


Paul

 

[Glenn]

Glenn,

Yes I agree, the stock selection is probably the last part of this because we know that we want to Short the weakest and Long the strongest stocks relative to INDU using whatever signal we get from whichever indicator we end up selecting. So in my view the focus for the testing team should now be entirely on which indicator to use.


Paul

To give some idea of the possibilties, here is a list of 24 indicators, mainly Ehler, for which the code is readily available and would just need tweaking to output the necessary GV's:-

-Sinewave
-Optimum predictor
-Adaptive RSI
-Adaptive Stochastic
-Adaptive CCI
-Fisher Transform
-Inverse Fisher Transform
-Cyber Cycle
-CG Oscillator
-RVI
-Stochastic RSI
-Stochastic Cyber Cycle
-Stochastic RVi
-Fisher Stochastic CG
-Fisher Stochastic RVi
-Fisher Cyber Cycle
-Adaptive Cyber Cycle
-Adaptive CG
-Adaptive RVI
-MACCI
-MACCI-653
-CCI
-RSI
-Stochastic

Added to this, some of these indicators can be adjusted using their Input parameters.
Also it may be possible to take a particular indicator and make it more adaptive than the standard code.

In addition, for identifying Trend or Cycle mode, there are things like
-Market Mode
-Instantaneous Trendline,
-MAMA/FAMA
-Or use a higher timeframe oscillator for Trends than for Cycles. e.g. ride the 30 min rather than the 10 min.
etc
etc

To test all these, plus any others, will require a lot of time and effort.
Glenn

 

[lote_tree]

First of all Glenn is absolutely right we need to know if we have a testing team or not.

There are many oscillators out there and some people on this BB have given us some very good ideas. In his last seminar Iraj mentioned a company called Mesa and encouraged us to take a closer look at some potential alternatives to the Macci. Let me first make one thing clear, neither I nor Iraj have any affiliations with Mesa!

I have modified one of John Ehlers’(from Mesa) indicators so that it can generate buy and sell signals in one TF, the ELA is posted below. Unfortunately I do not have enough coding acumen to create an indicator like A_B’s Macci MLT. I’ve coded it so that buy and sell signals will be generated when the RVI line crosses the trigger in the +2 and -2 zones. The indicator is called Fisher RVI, for those who need a brief explanation on how it works please read the PDF here:

http://www.trade2win.com/boards/tec...ogrammed-trade-development-10.html#post552930

The trickiest part of this research project is the entry criteria. Do we set simple or complex entry criteria’s (EC) from our MLT repertoire? Simple EC’s will obviously be easier to test. However, testing complex EC’s will provide a more accurate picture of an oscillator’s effectiveness in various market conditions.

I have an idea on how we can go about accurately testing different oscillators. If anybody has any other suggestions please feel free to air them, we are all in this together.

Our objective for this research project should be to test whether there are any superior oscillators out there to the Macci. If there are alternatives that we should adopt then their results should show this under lab conditions. I propose the following testing procedure:

1. Our first step, assuming we have a research group of full time traders, is to split the group into three. Group A will test the Macci and group B will test oscillator X. The testing will take place during market hours and will span 5 working days. Group C will back test both oscillators so that we have enough data for the results to be statistically significant. There must be at least two people in group C that can verify each others results when back testing both oscillators. Having different data sets can provide differing results due to data quality.

2. At the end of the week all three groups will collect their results. Group A and B will average out the results for their respective oscillators and pass that data on to Group C. Both groups A and B will keep a copy of the report they send to Group C.

3. Group C will collect the averaged results from both A and B and will add their findings to both oscillators. Group C will keep a record of the report that both A and B submitted. Group C will submit the overall report to the forum for scrutiny. The test results for the Macci will act as our benchmark. Any oscillator we test has to exceed our benchmark and it has to be statistically significant.

4. We will now be in a position to test new oscillators following the same procedure outlined above. The results we collect each week will be compared against the Macci. We can then create an overall table at the end of the testing phase for all to see. The TT forum can then have some confidence in the results because they will be conducted under lab conditions without any bias.

I think we need to be very systematic about this because this part of the project is probably the most critical. Our entry is the foundation for the systems success and we have to be super vigilant about what we decide to adopt as our entry tool.

Anybody who doesn’t have any coding experience and wants to contribute in some way can participate in this project as some of it only requires you to take entry signals. However, anybody who does volunteer must be able to keep accurate records and be disciplined enough to take every signal that’s generated. If during the testing phase somebody makes a mistake it’s important that they log it and present it in a separate report. The quality of the results will depend upon the ability of each member to work in a team and to take the project very seriously.

We are not here to have fun; we are here to make money and to build something together that will give us an edge over other traders for many years to come. Ok, the Obama segment of my speech is over!

Finally, I think we should take some of the burden off Charlton and Pedro. They have done a sterling job and put many hours into this. We have a responsibility to contribute just as much if we want to benefit from the final product. I agree with Iraj and think that a sub forum or some derivative be set up so that we don’t give our hard work away.

Cheers

Naeem

 

[pedro01]

Showing your 'experience' there Glenn - "set a bit" ??

It's 2009, we can use a whole byte now !

I agree that all we need to look for is the performance of the signal relative to the $INDU.

OK - for these indicators, perhaps we can classify them in order to help us. Alongside each indicator, do we know what kind of signals it throws off ? For instance - the MACCi simply looks for direction & zones (alert zone OB/OS). The MACCi 653 looks for crossovers.

If our members aren't so savvy in coding, then do you think we should try to group these indicators by the type of signals/entry rules we need to look for - then helping them with the code will be a lot easier.

Just a suggestion boss... :cheesy:

 

[lote_tree]

Oops, here is the code.

 

[Ultramarine]

I was thinking slightly differently
i.e. that initially all we need to do is test a variety of indicators using INDU data to see which gives the best result. i.e. the earliest Entry signals. At any turning point they will all give a signal at some stage, so the earliest would seem to be the winner.

Glenn,

Is this really the case or is it too simple? The ultimate test is profitability and an early signal may provide a worse outcome than a later one. If the mkt goes against you before turning in the direction you desire you might get stopped out. A later entry may have been "better". That will of course depend on your stop policy. If you shortlist your indicators on this basis and then move on to more realistic trading involving stops and targets (maybe I've missed this in the earlier posts but I can't remember seeing any discussion of exit strategies either) you may find you have eliminated the "best" indicator too early. So it depends on how it is planned to move on to the next stage. Measures of effectiveness are a bit of a minefield in system simulations. Sorry if that sounds a bit "Jonah-ish" - happy to be shown to be wrong.

Al

 

[Tantalus]

This one any use guys, seems pretty clean and unambiguous on the surface.