Program Trading: Trade Entry

Gentlemen
Now that we have some idea of how many can help and what they can do, it seems we have very few members who can cut code, so that may be a problem.
I was hoping that many tests could be run on the same day(s), using the same INDU data so that the results can be compared.
Basically that now means that for each indicator, the all code has to be produced by someone else (e.g. me) and passed to you individually so that you can run tests on it.
Glenn
Count me. My programming skills with EasyLanguage are quite good. I can prepare indicator's code for testing.

I'm going to test MTL CYCLE code during market hours today and compare results with historical backtesting.
 
Gentlemen

Basically that now means that for each indicator, the all code has to be produced by someone else (e.g. me) and passed to you individually so that you can run tests on it.
Perhaps there is also the issue of copyright regarding the Ehler code if you haven't got legal access to it.

Have to think about how to go forward and get back to you.
Thanks again.
Glenn

Glenn, looks like there are a few of us who can probably write some code although it may not be up to the standard of what you could produce. Maybe as a half way measure we less experienced contributors would submit code for review first before testing. Just a thought.

Regarding Ehler's code. A lot of it is freely viewable on his website as code listings so I doubt there is an issue with copyright. I use Sierrachart as well as TS and they have coded up some of his indicators and provided them in their product. Others are freely available on the SC bulletin board.

Jonnie
 
Glenn, I'd be happy to help out with EasyLanguage coding (I have a background in software development) starting out towards the end of the week. Give me a day or so to finish restoring my PC - should have stuck to XP!
 
I am willing to help as well.... Many members here have contributed a great amount of ideas and hours of time for this...

A questions could I run a test and trade during the day?? siorry if this is a retarded question... I have barely utilitized the full power of the software.

or could I do some testing after hours and see which osillator work better.

also I have not read any discussion regarding vwap in the systems we are working on, maybe we shoudl incorporate that study as well. maybe on a daily and cumulative basis? it uses time volume and price. jsut a suggestion here.

Moreagr
At present I think that any tests will have to be run during the day.
If you are trading at the same time then the tests will add some overhead to your processing, so it depends on how powerful your PC is and how much memory it has.
The way I'm thinking about testing at the moment means you would have 7 additional radars running each containing INDU, i.e. 6 for the different timeframes and one for the MTF analysis.

As regards VWAP I don't think that it will be part of the project, at least in the beginning. However it's not my decision.
Glenn
 
Glenn,

Ehler recommends taking signal crossovers when the Fisher CC, Fisher CG, and Fisher RVI cross above 2.00 for short or below -2.00 for long.

The Sinewave indicator is best used when the signal occurs at the peak or the valley of the last extreme cycle node.

The Inverse Fisher Transform when applied to RSI signals entry positions when the oscillator exceeds the +1 and -1 thresholds.

Naeem

Naeem
Thanks for that sir. Presumably the IFT could be applied to other indicators too.
Glenn
 
I have Tradestation Prosuite 2000i, I don't mind helping with the testing although my coding skills are close to non-exsistant - so if that is more trouble than its worth, then I will bow out.

I am not actively trading, so I do not mind running any indicators all day everyday, for however long that is required.

I currently do not have an active feed, as I do not know how to connect my 2000i to one - especially as I am on Windows Vista and eSignal no longer provide support for that. I know for Tradestation 8.3 you require OwnData, but I am not sure of the equivalent for 2000i.

If someone can point me in the right direction re: which data feed to use + how to connect it to Tradestation 2000i, than count me in as a tester.
 
i use 8.3 and can code el.....so pls let me know what is needed and i'll try to contribute.
 
If there are maybe up to 20 of us and we get offered $500M for the code can we agree that in these circumstances to vote on whether we wish to accept $25M each or not :)


Paul
 
Naeem
Thanks for that sir. Presumably the IFT could be applied to other indicators too.
Glenn

I have been testing a MLT version of the RVI TT and it does not produce good enough signals in my view. The problem is that you don't get a signal in all 3 time frames at once. I have it running on about 10 instruments and not one signal yet. I also changed the code so that the 1min, 3 min and 5 min only had to be at +2 or -2 and without the initial trigger of the crossover of the previous bar but still it has not given anything.


Paul
 
A disclosure must also be signed by all members ( please vote on this ) that the code is not sold or distributed

Not sure how that could work across numerous countries and continents. Sounds like u will need a separate legal team to go with the programming team.


similar code was sold $500 million to Morgan stanley by 5 students in USA

Best of luck to the group with this one !!


I also suggest team members be sacked or added depending on their contribution level ( by VOTE ) as some might join now and later leave the work to others ,, this is not fair )

It takes a heck of a lot more than code to be successful. You taught me that Iraj. Your psychology and profile must match the type of trading you are doing. You must have the capital, be able to pull the trigger (will floor a few no doubt) and having some balls too is useful. I learnt that Iraj's are made of steel :cool:

I wish the group well in their endeavours. I am not interested in jostling for position, or holding out the begging bowl in hopeful expectation :whistling

Thanks,
Frank
 
+


all codes on FTP server suggested by one of the main contributor ( password protected)


grey1

I strongly advise that hosting code on an FTP server is not the best way of managing a collaborative project of this nature.

The code does need to be under version control for a number of reasons:

1. Easy to reverse out mistakes made in code changes.

2. Audit trail of code changes.

3. Ability to maintain multiple versions of the code if so desired.

4. Managebility of code changes.

5. Release control.

Subversion is very widely used version control system in open source (and other) projects and is free:

subversion.tigris.org

Do not underestimate how important this is. There are many reasons that software projects fail, but lack of version control with multiple developers is almost a guarantee of (preventable) failure. The little bit of extra initial effort is well worth it.
 
I strongly advise that hosting code on an FTP server is not the best way of managing a collaborative project of this nature.

The code does need to be under version control for a number of reasons:

1. Easy to reverse out mistakes made in code changes.

2. Audit trail of code changes.

3. Ability to maintain multiple versions of the code if so desired.

4. Managebility of code changes.

5. Release control.

Subversion is very widely used version control system in open source (and other) projects and is free:

subversion.tigris.org

Do not underestimate how important this is. There are many reasons that software projects fail, but lack of version control with multiple developers is almost a guarantee of (preventable) failure. The little bit of extra initial effort is well worth it.

Thanks ,, I leave the comment about this matter to PETE ,, as I have no idea what FTP server is ,, I know swedish girls are gorgeous though if that helps in any way lol

Grey1
 
FTP Server is just a secure place to store the finished goods for contributors.

Work in progress is a different matter and whilst I do understand the need for source control & version control, this need increases with the number of developers & size of project.

With 3 or 4 developers & a decent set of specs, I don't think this will be an issue.

Now - in terms of my experience with these issues. I run a software company for a large Japanese multinational. We develop manufacturing software, programming languages and web portals. We use our own programming language (which my team develops), C, C++, MFC and Java.

I was a major contributor in the re-engineering of our internal software processes (a global effort, not just the Thai side) and have done a reasonable amount of consultancy work, mostly with Japanese multinationals, on software process improvement.

Anyway - all this trumpet blowing is to convince you that when this looks likely to become an issue, I will be ahead of the curve on it.
 
Naeem
Thanks for that sir. Presumably the IFT could be applied to other indicators too.
Glenn

Glenn,

That's correct. We tried applying the IFT to the Cyber Cycle oscillator. It works with stocks but doesn't compute anything useful when applied to the Dow unfortunately. We concluded that the problem may have been the higher price values of INDU.

I was thinking of applying the IFT to the CG and RVi oscillators but I'm still trying to figure out how to do that.

Naeem
 
I have been testing a MLT version of the RVI TT and it does not produce good enough signals in my view. The problem is that you don't get a signal in all 3 time frames at once. I have it running on about 10 instruments and not one signal yet. I also changed the code so that the 1min, 3 min and 5 min only had to be at +2 or -2 and without the initial trigger of the crossover of the previous bar but still it has not given anything.


Paul

Thanks Paul I was finding the same thing. However, I did notice that it seems very accurate with its turning points from both the 2.00 & -2.00 levels on the 10min chart.

Have you found that? I'm going to back test the Fisher RVI exclusively on the 10 min chart and see what results I can dig up.

Naeem
 
Iraj, a ftp (file transfer protocol) server is just a storage pc, no windows to view, just text based files.....boring stuff, unlike swedish girls.......which are much more fun!!!!!!!!
(hope the missues doesnt read this.......otherwise I'm toast!)
 
Would you like Fries with that sir ? :)

OK here we go:-

Crossovers of two signal lines (these all appear to ignore OB and OS levels, any opinions on that ?)
Sinewave
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

Indicator crosses over an upper or lower level (e.g. 30 and 70)
Optimum predictor
RSI
Stochastic

Indicator crosses Zero on the way up or down
Adaptive RSI
Adaptive Stochastic
Adaptive CCI

Turning Points + OB and OS levels
MACCI
CCI

Crossovers + OB and OS levels
MACCI-653

If anyone disagrees with any of the above, please let us know.
Glenn

For these indicators, do we also know
- how many inputs there are for each indicator (presumable length is in all of them)
- if the indicator is 'directional' like the MACCi - i.e. if it's pointing in a particular direction to indicate bias.

I ask this because it may be that some indicators are better for assessing bias & others for the trigger. We could output bias & trigger data so that we could also assess the prospect of a mix of indicators.

I think for each indicator, we need the rules for bias/trigger before we can test. Then I can develop the scripts we need for testing, it may be that only 3 or 4 scripts will cover them all.

Your thoughts ?

Cheers

Pete
 
For these indicators, do we also know
- how many inputs there are for each indicator (presumable length is in all of them)
- if the indicator is 'directional' like the MACCi - i.e. if it's pointing in a particular direction to indicate bias.

I ask this because it may be that some indicators are better for assessing bias & others for the trigger. We could output bias & trigger data so that we could also assess the prospect of a mix of indicators.

We can use indicators of 3 types:

1. TRIGGER type. Trading signal generates when it is in overbought/oversold area and
(a) changes direction or (b) crosses the signal line.
2. LEVEL type. Indicator shows overbought/oversold signals only when it is in overbought/oversold area.
3. DIRECTIONAL type. When indicator is rising - up trend, when it is falling - down trend.

The TRIGGER type indicator is used on 1 minute data, LEVEL type may be used on 3/5/10 minute, DIRECTIONAL type - 10/30/60.

When DIRECTIONAL type shows up trend, LEVEL type - oversold and TRIGGER indicator generates BUY signal we will buy and vice versa for sell.

Some indicators may work perfectly as one type indicator only. We should find the best TRIGGER indicator, the best LEVEL and the best DIRECTIONAL indicators.
 
Last edited:
For these indicators, do we also know
- how many inputs there are for each indicator (presumable length is in all of them)
- if the indicator is 'directional' like the MACCi - i.e. if it's pointing in a particular direction to indicate bias.

I ask this because it may be that some indicators are better for assessing bias & others for the trigger. We could output bias & trigger data so that we could also assess the prospect of a mix of indicators.

I think for each indicator, we need the rules for bias/trigger before we can test. Then I can develop the scripts we need for testing, it may be that only 3 or 4 scripts will cover them all.

Your thoughts ?

Cheers

Pete

Pete
In the pic below is what I had in mind for the indicator testing phase, which also seems to fit what you are saying to some extent.
Basically it's a Testbed comprising two chunks of code.
The first contains
a). the indicator as taken from a book or wherever
b). the additional logic required for this indicator to output it's signal to a GV (the box highlighted red and yellow). This additional logic would either be coded by the volunteer Tester if they have the skill, or by one of us. Your idea of a few standard scripts may not work because the indicators all have a variety or Variable names to label the plotted values.

In order to test one indicator across 6 timesframes, this first code would be set up 6 times, one for each timeframe, outputting to 6 different GV's.

(If instead the final product uses different indicators in different timeframes, as you and A_B may be suggesting, then that alters the picture altogether, and the testing with it.
At this stage I feel that we should only take one step at a time and determine the efficacy of each indicator used on it's own in a multi-timeframe setup. However I only get one vote like anyone else, so we'll see what the concensus is)

The second chunk picks up all the 6 GV's and determines if there is a composite signal. This code can be written once-only and need not change provided each tester uses the agreed GV names.
I'm assuming that the final operational code will use GV's, so whichever indicator 'wins', the code used in testing can be incorporated into the full system. The same would apply if the final product used different indicators in different timeframes.

my 2c

Glenn
 

Attachments

  • Testbed.JPG
    Testbed.JPG
    55.1 KB · Views: 36
Top