The perfect mechanical trading system. - page 4
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
So far, everything seems much simpler to me. You should start with some simple, naive system, with a minimum of tuning parameters, and add to it a block of adaptive parameter changes in real time...
There you go, there's very little left :) We need to decide what data to use to calculate the adaptive parameters. I don't even know what to suggest :(
Does anybody have any ideas in this regard?
I can start by proposing the following TC model:
We take simple Expert Advisor and write to it a block "tester" (whose task will be - once a day for example at 01:00 GMT to adjust TS under the monthly history).
xeon, the tester can be made to work all the time. Of course, it would have to be written in highly optimized C, not in mql4. Alas, there is one very serious pitfall in all this. Namely, it is the period of estimation and optimization of the system. I.e. for how long to evaluate its performance ? Suppose we have two strategies competing for the right of real trading. The successful current one and the worst one. Within an hour, for example, the current strategy has lost money, while the back-up strategy on the contrary was successful. The question is to change strategies or not to change? After all, this can be the beginning of a new trend (not to be confused with trend/flit !), or accidental. I.e. it turns out that such a tester itself would have at least one (and important !!!) configurable parameter - the evaluation and optimisation period. Don't get the idea that I'm saying that such an approach is impossible. I'm just saying that there are difficulties and obscure places in all this.
Let's try a simple approach after all.
The task: is it possible to write a function that runs the monthly history once a day and sets the optimal number for the stop loss parameter?
AND THE GREATEST THING: Can I use this function to check the tester? Will the tester work at all? It turns out that every day in the test mode it should change the parameter of stop for a new day? Is it possible? If this task is solved, the rest is icing as already said.
xeon, a tester can be made to work all the time. Of course it would have to be written in highly optimized C, not in mql4. Alas, there is one very serious pitfall in all of this. Namely, it is the period of estimation and optimization of the system. I.e. for how long to evaluate its performance ? Suppose we have two strategies competing for the right of real trading. The successful current one and the worst one. Within an hour, for example, the current strategy has lost money, while the back-up strategy on the contrary was successful. The question is to change strategies or not to change? After all, this can be the beginning of a new trend (not to be confused with trend/flotation !), or it can be accidental. I.e. it turns out that such a tester itself would have at least one (and important !!!) configurable parameter - the evaluation and optimisation period. Don't get the idea that I'm saying that this approach is impossible. I'm just saying that there are difficulties and obscure places in all this.
Let's try a simple approach after all.
The problem: is it possible to write a function that runs the monthly history once a day and sets the optimal number for the stop loss parameter?
AND THE GREATEST THING: Can I use this function to check the tester? Will the tester work at all? It turns out that every day in the test mode it should change the parameter of stop for a new day? Is it possible? If this task is solved, the rest is icing as already said.
As far as I know, it is possible to write such a function in mql, but it is not an easy task for me, because I am an "amateur programmer" and I need time to do it.
Self-adjusting indicators are a dead end. I will try to justify my opinion.
I have developed several such indicators, but they appeared to be sensitive to volatility of quotes coming from different brokerage companies. That is, these indicators work fine on data of one brokerage company and do not work at all on data of another one. Worst of all they work with TC data. For example on the standard indicators on the same quotes interval there is divergence in one brokerage company and not in another.
My research showed that volatility is the leading factor to be considered in a self-tuning indicator. However, eventually the indicator becomes dependent on the filtering method of quotes in different brokerage companies and on the changes of this method (that is not notified by brokerage companies).
Here I also faced with the fact that I cannot "harden" (as Renat always says) the self-tuning, because it is constant (linear), and not discrete.
I believe that the only way to avoid the volatility problem is to ignore the absolute values of indicators and quotes. I.e. to make a decision in MTS we should use the correlation of values in one form or another, and this is in fact pattern recognition.
it!
Self-adjusting indicators are a dead end. I will try to justify my opinion.
I have developed several such indicators, but they appeared to be sensitive to volatility of quotes coming from different brokerage companies. That is, these indicators work fine on data of one brokerage company and do not work at all on data of another one. Worst of all they work with TC data. For example on the standard indicators on the same quotes interval there is divergence in one brokerage company and not in another.
My research showed that volatility is the leading factor to be considered in a self-tuning indicator. However, eventually the indicator becomes dependent on the filtering method of quotes in different brokerage companies and on the changes of this method (that is not notified by brokerage companies).
Here I also faced with the fact that I cannot "harden" (as Renat always says) the self-tuning, because it is constant (linear), and not discrete.
I believe that the only way to avoid the volatility problem is to ignore the absolute values of indicators and quotes. I.e. to make a decision in MTS we should use the correlation of values in one form or another, and this is essentially pattern recognition.
For any system, it is not the price values that are important, but the speed of price change (sometimes just the sign).
Sometimes price acceleration is used (estimating the force acting on the price, as a leading indicator).
ALL indicators used with MTS are in fact designed to estimate the speed.
Different indicators are simply different OPTIONS to estimate velocity.
1. ALL oscillators estimate speed, sometimes acceleration (like MACD).
2. ALL moving averages are NEVER used on their own,
only in comparison with other moving averages (price is a muving with length = 1).
This comparison of the moving averages (actually comparing their difference to zero) is an oscillator.
3. It is not the price that needs to be considered, but the logarithm of the price.
In logarithms everything becomes simpler and more correct.
For small changes in price, there will be no difference between working with price and the logarithm,
With large changes in price, the difference will be significant.
Can I give you a little hint? :)
For any system, it is not the value of the price that matters, but the speed of price change (sometimes just the sign).
Sometimes price acceleration is used (estimating the force acting on the price, as a leading indicator).
ALL indicators used with MTS are in fact designed to estimate the speed.
Different indicators are simply different OPTIONS to estimate velocity.
1. ALL oscillators estimate speed, sometimes acceleration (like MACD).
2. ALL moving averages are NEVER used on their own,
only in comparison with other moving averages (price is a muving with length = 1).
This comparison of the moving averages (actually comparing their difference to zero) is an oscillator.
3. It is not the price that needs to be considered, but the logarithm of the price.
In logarithms everything becomes simpler and more correct.
For small changes in price, there will be no difference between working with price and the logarithm,
at large price changes the difference will be significant.
Or maybe you'd like to take part in writing the code as well? :-), with your programming experience it would go much faster!