Phoenix optimization - page 15

 
autumnleaves:
Thank you to Daraknor, Azbo, Bert, and others for their feedback and general contribution to our common cause. Just a few comments on optimization and development first.

I appreciate that Phoenix 6 will likely be a quantum leap ahead of version 5xx, but I wonder then what is the purpose of optimizing older versions. Many people are still running 5.6 and 5.7.0, and I have even been discouraged from testing 5.7.2.

Moreover, there are now 2 different versions of 5.7.2W, and it is not clear which one should be used in testing or optimizing. Preliminary tests show that backtesting with a TP near infinity is problematic. It appears that open trades prevent others from opening, and then all the remaining open trades close on Grace at the end of the backtest period. It is difficult to draw any conclusions from this.

5.7.2W - the W is for Wack it is not the official latest version. I call it the bleeding edge. I created this version so that I could work on peoples suggestion and keep new development going while Daraknor works on 6.0. I have improved that version a few times. The latest version is the best version. If you don't want to use the updated features of this version then you just leave the TS and the decreasefactor = 0. Each newer version is better that the previous.

Some people are asking about these features so, I checked into them and created something that allowed people to use them. The other key complaint of people was that they wanted to be able to optimize with essentially reversed values on one of the signals.

I don't want to discourage anyone from using 5.7.2.W. Lets discuss your point. TP near infinity is problematic - The trade will not close as long as it is going up and hasn't come down to his the TS. That is how TS is supposed to work. That is what some people asked for. It appears that open trades prevent others from opening. Yes that is always going to be true. Here is something that may help you with that.

extern int U_M12_MaxTrades = 1; //set to number of trades to open

You can increase this number and it will allow that many trades to be open at once. I know that, you can get buys and sells in any combination open at the same time. This has some implication for the risk. Once any one of the trades close, you can then open another one. I do not understand fully myself, how quickly they will open. Daraknor gave me an answer on this, but I didn't understand it.

I attached a little sample of the effect of increasing the max trades. Profit increased, but so did max drawdown. For the purposes of testing out the code, I do not run huge tests.

You can do your optimization with 5.7.0 if you want, or 5.7.2.w. Just wait until you have a good result before you start using the new feature. See if any of the new features in combination with your optimization will improve your results.

Files:
 

A big warning for everyone, FXDD downloaded data is NOT the same as FXDD data from the servers. Mixing the two will corrupt your history because the prices are about 15-20 pip apart. I wonder which one is closer to the OTC market between brokers?

Be warned, and know that all backtests should be done on a disconnected installation.

 
daraknor:
A big warning for everyone, FXDD downloaded data is NOT the same as FXDD data from the servers. Mixing the two will corrupt your history because the prices are about 15-20 pip apart. I wonder which one is closer to the OTC market between brokers?

When you say "downloaded data" do you mean that FXDD has a data bank similar to Alpari?

JRtrader

 

FXDD has a link where you can download history data. It isn't from the "download" button. http://www.fxdd.com/mt1m_data.html

I have noticed enough differences between the two history sets for recent data that I don't trust this downloaded data for optimization. It isn't FXDD published quotes for sure. Mixing the two = corruption.

 

Odd stop loss behaviour

Here is an anomaly. Backtesting 5.7.2W on GBPUSD, a buy was entered at 18574 and went out on SL at 1.8553, even though the SL was 30. Is this New Math or is there another reason why SL triggered long before it should have?

 
autumnleaves:
Here is an anomaly. Backtesting 5.7.2W on GBPUSD, a buy was entered at 18574 and went out on SL at 1.8553, even though the SL was 30. Is this New Math or is there another reason why SL triggered long before it should have?

I did a backtest and I didn't see a problem like that. In real testing it can happen, through slippage. TS could cause this to happen

 

Trailing Stop Anomaly

Thanks for your feedback PContour. I have tried to look at this in more detail, and I find that either I don't understand trailing stop, or TS in Phoenix 5.7.2W is not working as it should.

In the example below (with TS20 and SL10) the sale is taken out at 1.8555. A minute or so later SL is moved from its original position (1.8565) to 1.8564, and TP has become 1.8524. The difference between SL (which is now trailing) and TP is 40. But TS+SL=30.

Furthermore, shouldn't the EA wait until the trade is 20 pips in profit, and then move the SL to breakeven before allowing it to trail?

I also wonder why the TP is modified every time the SL changes. In this case, 20 pips of profit were lost due to shifts in the TP.

1 2006.10.16 00:13 sell 1 0.10 1.8555 1.8565 1.7556 0.00 10000.00

2 2006.10.16 01:28 modify 1 0.10 1.8555 1.8564 1.8524 0.00 10000.00

3 2006.10.16 01:57 modify 1 0.10 1.8555 1.8563 1.8523 0.00 10000.00

4 2006.10.16 01:59 modify 1 0.10 1.8555 1.8562 1.8522 0.00 10000.00

5 2006.10.16 02:00 modify 1 0.10 1.8555 1.8561 1.8521 0.00 10000.00

6 2006.10.16 02:00 modify 1 0.10 1.8555 1.8559 1.8519 0.00 10000.00

7 2006.10.16 02:16 modify 1 0.10 1.8555 1.8558 1.8518 0.00 10000.00

 

To optimize or not to optimize

Given the apparent defects in historical data available from the various brokers, I wonder if an alternative exists.

a) could we find a source of "uncontaminated" data, e.g. by paying for it. There is a fellow in one of the forum who distributes "fixed" Alpari data.

b) should we give up on backtesting with historical data altogether, and do forward testing only, combined with visual reckoning using live indicators on charts.

I would like to do more of option b) but it becomes rather tedious to set up the indicators all the time. If they were built into Phoenix this might be a very interesting alternative.

Any suggestions.

 

I noticed my FXDD data download was 'corrupted' by having chart data mixed with downloaded data. Also keep in mind that one tick spikes do happen in the market and in the data. Metatrader has improved over the years because now it won't let you trade 1 tick price action - but trades will still exit on a single tick.

 
autumnleaves:
Given the apparent defects in historical data available from the various brokers, I wonder if an alternative exists.

a) could we find a source of "uncontaminated" data, e.g. by paying for it. There is a fellow in one of the forum who distributes "fixed" Alpari data.

b) should we give up on backtesting with historical data altogether, and do forward testing only, combined with visual reckoning using live indicators on charts.

I would like to do more of option b) but it becomes rather tedious to set up the indicators all the time. If they were built into Phoenix this might be a very interesting alternative.

Any suggestions.

As I read from you, you are doing a crazy "alternative" Autumn : "twisting" settings until to change an counter trend EA to a following trend EA.

Big job !

Great job !

Huuuu!

Why not ?!

Reason: