Suggestions for EA (Loosing to Profit) - page 7

 
diostar:

No. That's not really it, at this stage. It CAN be a waste of time, testing from buy to sell, vice versa, though it did give changes. When I say, this is what I meant:

Finding the best solution in the most minimal of time. While in same (very short) time, 5-10 mins at most, test per unit logic, so the logic CAN be a determined one, say. 99% good or 99% bad, is pretty much confirmed.

1) You just take 1 master logic, say for eg:

and remove all the rest, and you do this:

that is per unit logic - testing BOTH buy and sell, at the SAME time. So, if you wish to go optimization with this 1 master logic, you will simply optimize on your basic parameters - sl,tp, lots, etc only. Then analyse the instances of their buys and sells, judge whether if this 1 logic is can make the cut, in both scenarios - whether it makes an incorrect or correct entries. Both. Then move on, to the next logic.

As you get along, you might want to try combinations...1st logic just buy, logic 2, just sell, or both, etc. I find this way is more structured and you can really see which precise logic is really causing the drawdown.


I have never tested an EA with these methods, so bare with me pls...

My question is: what parameters do I isolate to strictly focus on profit?

  • MAs?
  • TP
  • SL
  • ?
 
c0d3:

I have never tested an EA with these methods, so bare with me pls...

My question is: what parameters do I isolate to strictly focus on profit?

  • MAs?
  • TP
  • SL
  • ?

Neither did I. I just stumbled on this totally new idea while working on this. I came from a pretty technical grounding, so it was easy for me to judge that some logic is completely incorrect/biased/flawed, on the markets.

But I was asking, "How can this be proven on the strategy tester, if its truly so? Surely there must be a way." So I chance on this method, coincidentally.

You just take, in this case, those MA logic in checkcondition, one by one, say for eg, you start with M240close< MA 240. YOu test both sides - buy and sell, AT THE SAME TIME. Now these are the cases:


1) Now, mathematically, if this logic is indeed feasible, the result should be somewhat NEUTRAL, since it covers both sides. Agree? If it turns out profitable - then you can conclude by looking thru, buy and sell results, this logic is making the cut very, very well, even while it is taking punches from the opposite. So it is very sound.

2) Now, if it turns out disastrously, then you can conclude, that the WHOLE logic i.e. comparing the close at 240 with MA 240, is 100% flawed against all sorts of market movements. So that should leave you convinced that the whole logic should be taken off, replaced altogether.

Leave the rest - tp, sl, for optimization. Its getting the logic, piece by peice, correct which is more important at this stage.

Since using this approach, I have had quite good progress with my own. Before, I was doing things pretty much the same as many, but with this new way, I am making serious progress in very very short time..;-)

 
diostar:

Neither did I. I just stumbled on this totally new idea while working on this. I came from a pretty technical grounding, so it was easy for me to judge that some logic is completely incorrect/biased/flawed, on the markets.

But I was asking, "How can this be proven on the strategy tester, if its truly so? Surely there must be a way." So I chance on this method, coincidentally.

You just take, in this case, those MA logic in checkcondition, one by one, say for eg, you start with M240close< MA 240. YOu test both sides - buy and sell, AT THE SAME TIME. Now these are the cases:


1) Now, mathematically, if this logic is indeed feasible, the result should be somewhat NEUTRAL, since it covers both sides. Agree? If it turns out profitable - then you can conclude by looking thru, buy and sell results, this logic is making the cut very, very well, even while it is taking punches from the opposite. So it is very sound.

2) Now, if it turns out disastrously, then you can conclude, that the WHOLE logic i.e. comparing the close at 240 with MA 240, is 100% flawed against all sorts of market movements. So that should leave you convinced that the whole logic should be taken off, replaced altogether.

Leave the rest - tp, sl, for optimization. Its getting the logic, piece by peice, correct which is more important at this stage.

Since using this approach, I have had quite good progress with my own. Before, I was doing things pretty much the same as many, but with this new way, I am making serious progress in very very short time..;-)

Why not just optimize all the varibles at the same time? It may take a while to run to the optimization test but, thats why I have 2 computers. One for testing, one for development.

Assuming you have a shell EA that functions properly, ie, SL, TP, Trailing SL, Increment, Stack, Risk, lots hours to trade, email, reporting, opening closing orders, works on multiple pairs etc. Assuming all of that works properly, which is no minor task, you are then left with whatever logic you use to enter a trade. In my case I have Trade() that returns 1,0 or -1. The logic in Trade() can be whatever system you want to plug in.

I test my trade logic\system in visual mode first, so I make sure the logic is functioning properly, for example the stops are set in the correct place, the entry is in the correct place\bar\level and whatever the system calls for. Once that is done, generally this takes an hour or soto test unless I have completely lost my mind. I then run the whole optimization for ranges of TP,SL Stack, Trade hours and whatever variable need to be tested within the trade logic Ma, bars patterns whatever.

If you run all of you optimizations and the same time it will give you a better idea if the strategy works. If you want to cut the time testing down run a opt for a shorter period of time, just to get a taste of the system, say 1-2 months. This should not take very long 4-8 hours or so if you keep you ranges down. If it looks promising then run a real backtest that will give you real sense of how the system is working. Nothing says you can't stop a backtest after a 100 runs becasue it looks like a loser already.

In my testing I am looking at drawdown as my number one stat, If my EA draws down more then 12% with a 2% risk then I am back at square one anyway. If that works out I look at win\loss percent, and average win to average loss ratio. I'm not sure you are going to get those numbers any faster by doing it your way. If most, 80-90% of my opt runs don't draw down the account to 0 then you have a decent shot at a profitable EA. I then take the middle profit runs and average and reoptimize with smaller ranges to get my settings for a foward test on live data. That alone can take a month. I would not run with real money unless that was done.

Ingnoring all of the above, this is just the way I do dev work, at least with EA's.

I don't agree with 1 or 2.

1) I don't think you can prove or even know if the system will be profitable unless you run a opt run through the backtester with every variable possible. What if, SL,TP,Stack, distance between Stack, or MoveStop makes the stratagy a winner, It's not really a what if, it is a fact. If you test your way you still need a SP or TP or whatever to see a win or loss. If you have a 100 pip SL on a 1 minute chart you are most likely going to have a great system with 85 -> 98% wins. I can tell you it will not perform that way when you run it though an optimize run. You can have a 30% win ratio and a very profitable EA. You can also have a 90% win rate and the drawdown could be 70% and 3000 out of 4000 opt runs drain the account. In the end you are going to do a full run anyway. Why not do it first and code a new system in parallel.

2) It could turn into a disaster and you toss a system without a full test. It might be like tossing a winning powerball ticket in the trash because you just checked the powerball number and you know you didn't hit the jackpot. You did have the other five numbers and you just tossed a 250K winner into the trash, now some pigeon has a really expensive nest.

Bottom line is I think the actual coding of the system is the least time consuming part of the developement process. The testing is the longest and most important part and I want to spend most of my time in the testing phase. I also tend to learn more from my failed EA's, I know this is what everyone says, but failures in testing tend to help narrow down parameter ranges for future optimizations, this makes testing the more promissing EA's faster in the end.

Just my 2 cents.

 
danjp:

Why not just optimize all the varibles at the same time? It may take a while to run to the optimization test but, thats why I have 2 computers. One for testing, one for development.

Assuming you have a shell EA that functions properly, ie, SL, TP, Trailing SL, Increment, Stack, Risk, lots hours to trade, email, reporting, opening closing orders, works on multiple pairs etc. Assuming all of that works properly, which is no minor task, you are then left with whatever logic you use to enter a trade. In my case I have Trade() that returns 1,0 or -1. The logic in Trade() can be whatever system you want to plug in.

I test my trade logic\system in visual mode first, so I make sure the logic is functioning properly, for example the stops are set in the correct place, the entry is in the correct place\bar\level and whatever the system calls for. Once that is done, generally this takes an hour or soto test unless I have completely lost my mind. I then run the whole optimization for ranges of TP,SL Stack, Trade hours and whatever variable need to be tested within the trade logic Ma, bars patterns whatever.

If you run all of you optimizations and the same time it will give you a better idea if the strategy works. If you want to cut the time testing down run a opt for a shorter period of time, just to get a taste of the system, say 1-2 months. This should not take very long 4-8 hours or so if you keep you ranges down. If it looks promising then run a real backtest that will give you real sense of how the system is working. Nothing says you can't stop a backtest after a 100 runs becasue it looks like a loser already.

In my testing I am looking at drawdown as my number one stat, If my EA draws down more then 12% with a 2% risk then I am back at square one anyway. If that works out I look at win\loss percent, and average win to average loss ratio. I'm not sure you are going to get those numbers any faster by doing it your way. If most, 80-90% of my opt runs don't draw down the account to 0 then you have a decent shot at a profitable EA. I then take the middle profit runs and average and reoptimize with smaller ranges to get my settings for a foward test on live data. That alone can take a month. I would not run with real money unless that was done.

Ingnoring all of the above, this is just the way I do dev work, at least with EA's.

I don't agree with 1 or 2.

1) I don't think you can prove or even know if the system will be profitable unless you run a opt run through the backtester with every variable possible. What if, SL,TP,Stack, distance between Stack, or MoveStop makes the stratagy a winner, It's not really a what if, it is a fact. If you test your way you still need a SP or TP or whatever to see a win or loss. If you have a 100 pip SL on a 1 minute chart you are most likely going to have a great system with 85 -> 98% wins. I can tell you it will not perform that way when you run it though an optimize run. You can have a 30% win ratio and a very profitable EA. You can also have a 90% win rate and the drawdown could be 70% and 3000 out of 4000 opt runs drain the account. In the end you are going to do a full run anyway. Why not do it first and code a new system in parallel.

2) It could turn into a disaster and you toss a system without a full test. It might be like tossing a winning powerball ticket in the trash because you just checked the powerball number and you know you didn't hit the jackpot. You did have the other five numbers and you just tossed a 250K winner into the trash, now some pigeon has a really expensive nest.

Bottom line is I think the actual coding of the system is the least time consuming part of the developement process. The testing is the longest and most important part and I want to spend most of my time in the testing phase. I also tend to learn more from my failed EA's, I know this is what everyone says, but failures in testing tend to help narrow down parameter ranges for future optimizations, this makes testing the more promissing EA's faster in the end.

Just my 2 cents.

Well, then lets agree to disagree....and thanks for writing really long post. maybe this article will do. optimization = TRAP, you can fall in. https://www.mql5.com/en/articles/1434

 

@c0d3: Here's an advice which was given to me by some great developers on this forum. Don't ever use the Strategy Optimizer (except for fine tuning). The ideal development process is: 1) You think a strategy makes sense. 2) You code & test the strategy. 4) The strategy comes out profitable. 5) You use Optimizer to fine tune. 6) You learn from the areas where it failed.

The optimizer is a #-cruncher which would make 1-pip Sl/Tp become the difference between win or lose. Optimizing the variables 1-at-a-time or all-together makes no difference, IMO. Here's my holy-grail when I was 1-Month new. If it was that easy, I wouldn't still be looking for better methods.

 
ubzen:

@c0d3: Here's an advice which was given to me by some great developers on this forum. Don't ever use the Strategy Optimizer (except for fine tuning). The ideal development process is: 1) You think a strategy makes sense. 2) You code & test the strategy. 4) The strategy comes out profitable. 5) You use Optimizer to fine tune. 6) You learn from the areas where it failed.

The optimizer is a #-cruncher which would make 1-pip Sl/Tp become the difference between win or lose. Optimizing the variables 1-at-a-time or all-together makes no difference, IMO. Here's my holy-grail when I was 1-Month new. If it was that easy, I wouldn't still be looking for better methods.

These points are exactly what the article had on optimization. And my own personal take too of the tester. I'm quite surprise why even advised the otherwise. Business contradictions?

All in all, trading is a relatively "simple" game, if you consider this fact. Nobody, not even the genius ones at it trades all day long like some robots do - the good, exceptional ones takes only 15-30 min, at most 1 hour to enter, pull out 70-100 pips trail and go off for lunch. Sounds hard enough for a robot? If you can do that weekly, or daily, and love doing it until you're old like that old lady from YTE, that's what i called a holy grail. not some robot that needs tinkering forever.

But perchance, you want to complicate things with a robot, then be prepared to have at fingertips certain know-hows of what really makes a computer program tick, beside markets. You may need abilities that covers several areas, not just programming, but also fundamental topics - boolean logic is a definite one, mathematics and engineering insights will be helpful, etc, etc. These can be beyond some people.

If you want to know more, what i can share hopefully is testing and optimiziation, is nothing more than a clever mechanical statistician force to churn data by some logic YOU gave it to follow. But truth is, markets dont work by statistical laws or YOUR logic, if you havent find that out, yet.

I have well-recommended commercial EAs, that gave pleasing backtests results, yet still gives me huge, huge drawdown esp. for the past months. Now, If you have been thru that, you will know better what I mean. There is such a thing as a holy grail, but definitely not a mechanical one that requires tinkering just to fit the moment. And its glorious backtest results.

My advice is this: take this tinkering as a hobby and take trading SEPARATELY. If you wish to combine them both,then be prepared to be its own sacrifice, in the long run.

 

99% of people who trade Forex will lose. These are Not-Robot traders. Robots are not evil, its a tool. The robot is only as good as the money and time you pay for them. ;)

 
diostar:

Well, then lets agree to disagree....and thanks for writing really long post. maybe this article will do. optimization = TRAP, you can fall in. https://www.mql5.com/en/articles/1434


Optimization is a trap if you let it trap you. I use Optimization to get as many trades in as possible over some number of years. While I am doing something else. I would not put a cent of my money with a robot that hasn't been tested, backetested and foward tested. The problem is time, how long are you going to wait to trade real money. I have been trading for 5 years or so, the benifit of a robot over a humen is this, it does what you programed it to do. It does not turn on CNBC and listen to what some idiot think, it does not wait for a new release, it does not get nervous or stop a trade early becuase it had a feeling the market was going to turn. It also works if you are not a full time trader.

If you run 12,000 simulations in the optimizer and 70% of those runs fail, and 10% of the runs earn you 2000% or whatever crazy number people are looking for then you pretty much have a losing system and it's not worth the time testing it.

If you think your are going to test a system manually over a number of years and tweak it after every run changing one parameter at a time, thats more insane then running the optimzer . However if you run say 15,000 passes in the opt and none of those passes is a loser then you have a system that is ready to at least drop into a demo account for foward testing for say 4 weeks. BTW at this point you are going to find the real coding bugs.

Show me a person who trades 15-30 minutes a day and banks 100-150 pips and then is off to lunch, I'll show you someone who does not trade real money. Trading is a full time job just like any other job.

If this is a hobby, I'm not sure why you would waste time doing this this type of coding. It's pretty easy technically and your not going to make nearly as much money as you would in a normal develpement job. I work on a system in my day job that has close to 2 million lines of code using 4 langs and runs on mainframes, PCs, every flavor of UNIX and most Linux op systems.

In my humble opinion, the article was interesting. That does not mean I believe every word in it. It's just the opinion of the author, They probably had to run lots of optimizations to come to the conclusion that optimazion is a trap. If they did that, then how can the article be correct since optimization does not work.

 
ubzen:

@c0d3: Here's an advice which was given to me by some great developers on this forum. Don't ever use the Strategy Optimizer (except for fine tuning). The ideal development process is: 1) You think a strategy makes sense. 2) You code & test the strategy. 4) The strategy comes out profitable. 5) You use Optimizer to fine tune. 6) You learn from the areas where it failed.

The optimizer is a #-cruncher which would make 1-pip Sl/Tp become the difference between win or lose. Optimizing the variables 1-at-a-time or all-together makes no difference, IMO. Here's my holy-grail when I was 1-Month new. If it was that easy, I wouldn't still be looking for better methods.

  • I strongly agree, back-testing is only good to test logic(technical, visual), and should never be used as a gauge for profit potential
  • Hence, i only forward test EAs to measure their performance, so things like optimization is a completely new subject, which I'm still skeptical about
 
danjp:

If you think your are going to test a system manually over a number of years and tweak it after every run changing one parameter at a time, thats more insane then running the optimzer . However if you run say 15,000 passes in the opt and none of those passes is a loser then you have a system that is ready to at least drop into a demo account for foward testing for say 4 weeks. BTW at this point you are going to find the real coding bugs.


This is a good point, about back-testing

Reason: