no (try to replace OP_BUY with OP_SELL & find out)
this was exactly what happened the other day, and it turns out like that. That's why I post this.
And...
A poor Buy entry does not neccessarily make a good Sell point either!
-BB-
And...
A poor Buy entry does not neccessarily make a good Sell point either!
-BB-
So what I am getting at here is rather: the efficiency of an EA builder, his or her approaches to strategy findings, approaches to test work, optimization, could this be an easier way?
As far as I know, people tend to take head on with their EA, rule 1, rule 2, rule 3, etc,.. then test, then result. And they go back to their tinkerings, and the test cycles repeats.
I am questioning the approach.
And it happened as well, the other day.
What happened the other day? Did you make a good EA out of a Bad EA or something?
Will this be an easier approach to have a better EA, in the long run?
What's a better EA in the long run? As you're not considering: Profit or Trading for that matter.
the efficiency of an EA builder, his or her approaches to strategy findings, approaches to test work, optimization, could this be an easier way?
Like qjol said. No. (Thats also my Opinion)
I am questioning the approach.
Its fine to question the approach. However your approach of working with the reverse of the worse results is not all that appealing either. If you asking whats easy process to system development then my answer is here.
ubzen:
Its fine to question the approach. However your approach of working with the reverse of the worse results is not all that appealing either. If you asking whats easy process to system development then my answer is here.
Yes, this is what I was questioning. I should have simply use - System Development Process, or rather, EA Development Process. Im far from such IT terms, this word is just totally new.
Some other fields, there is process called Systems Engineering, and Reverse Engineering is a highly sought part in it. It is helpful in determining what, how circumstance happened eg. plane crash, accidents, forensics, etc, and they approach pretty much the same, putting bits and pieces into a test lab, reverse the scenario, forward the scenario, scale up, down, etc.
In crpytography, this concept is also widely applied, but it takes a different form - its usually the efficiency of having the most nearest solutions in the minimal time, or man-hours. This form is what I'm after, and like to know whether anyone else has found their own efficient methods in EA Development Process.
I am working on to sit at most 5-10 minutes on 1 logic on a tester, then move on to next, etc, etc, or call it a day. It seem an agonising slow process, but I just discovered the other day, I may be all wrong.
ubzen Thanks for sharing, I will have a read from the link your posted. Thanks to everyone too for your comments.
i have looked thru that link you gave. It is very informative. Thanks. Those are really about an analysis of outcomes from an EA, a deeper look at results using statistics to work on the key tester's values. It is AFTER an EA has been developed. I was looking more at DURING the process of EA development, not just after - what can make it easier, knowing whats good whats bad much faster. Thanks.
![MQL5 - Language of trade strategies built-in the MetaTrader 5 client terminal](https://c.mql5.com/i/registerlandings/logo-2.png)
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
Suppose you create an EA. A very, very simple EA, with just a simple, one logic. Run on the tester, and it turns out the worser, the better. This becomes your "Evil Grail".
Next, just reverse that evil grail's logic. Continue with the next logic...
Will this be an easier approach to have a better EA, in the long run?