Phoenix - Development+Suggestions - MQ4 in Post#1 - page 16

 
daraknor:
please let me know if anyone has errors. 5.7.0 will automatically assume control of existing trades.

Great piece of work! just a quick check and outstanding mode 3 results. Most excellent! see attached backtest graph.

Files:
 

Supports and Resistances

Hi.

I've got one question :

Could we include the concept of Supports and Resistances in Phoenix ?

I explain :

Following forward testing, i've seen, for exemple, today, phoenix take a SELL position @ 3 pips of the Daily support of USDJPY.

And of course, as the support playing is role the pair goes UP (so wrong trade direction).

If we include the concept of support and resistance when Phoenix decide to place a trade, it's will be more accurate no ?

Any opinions ?

Thanks for sharing.

 

Settings in 5.7.0

daraknor:
please let me know if anyone has errors. 5.7.0 will automatically assume control of existing trades.

What settings are recommended for 5.7.0? I presume that all previous optimization is out the window.

 
dswk:
Hi.

I've got one question :

Could we include the concept of Supports and Resistances in Phoenix ?

I explain :

Following forward testing, i've seen, for exemple, today, phoenix take a SELL position @ 3 pips of the Daily support of USDJPY.

And of course, as the support playing is role the pair goes UP (so wrong trade direction).

If we include the concept of support and resistance when Phoenix decide to place a trade, it's will be more accurate no ?

Any opinions ?

Thanks for sharing.

We have two major changes planned for Phoenix 6. The first we have been rather public about and that is trend analysis. Phoenix 6 won't fight strong trends anymore. The second addition is a bit harder and I've been working on it quietly as my main project: Murrey Math support and resistance lines. We might also do Gann style weekly/alltime support and resist based on 12.5% 50% and fibonacci over height, but it is likely that we won't need it. A vagure "hey this S-R line is getting close" would be a great confirming signal. We might restrict Phoenix to only trade when close a S-R line, or never trade opposite one (never set a profit level that requires violation of S-R line). I am still unclear how convert that to a simple True/False indicator but my EA is progressing nicely.

 
autumnleaves:
What settings are recommended for 5.7.0? I presume that all previous optimization is out the window.

If you optimized Mode1, same settings. If you optimized Mode3 specifically, then it may be back to the drawing board depending on how much of the settings were customized to increase the performance of the bugs. The Mode3 settings you used before are a great place to start though.

 
daraknor:
Removed Global Variable Code for mode3

Rewrote all SL detection and trade morade tracking code.

No more history file checks

No more trade monitoring

Vastly increased performance

Added 3 variables for controlling the 3 trades in mode 3.

Variables added to the Mode3 settings area

Changed default mode3 settings TP multiplier

Suggestion on use of mode3: This behavior is much different than previous versions because the code actually works. If you want a system similar to the previous mode 3, set the first trade to have the highest multiplier. For example, T1adj=1.3 T2adj=1.0 T3adj=0.7 When the price hits 0.7*TP the second trade will have SL moved to breakeven. Trade1 will never have the SL adjusted, only Trade2 and Trade3.I dodn't want to change the settings on people, but the performance was so poor I added these optional settings.

Mode1 is still default, Mode3 is still needing testing but it will likely have poor performance until the nonbugged version is optimized. Previous mode3 optimizations were really optimizing bugs, not mode3 as intended. I ran 5 tests on 3 different data sources and had no bugs.

Hi Darak

Nice job

Can you be a little bit more specific on your suggestion to use Mode 3 ?

I am not sure to get the point.

Thanks

 
 

Vince, thank you very much. I found that 5.6.8 didn't have any bugs in mode3 for a while. Then for some unknown reason, it kept imploding and had a massive string of errors. I originally thought it was the trade data we were sending, and I kept refining those settings and the trade over and over, increased the error logging, tweaked the settings more. The code looked solid, performed most of the time, and then just broke. You might be able to run it 2-3 months before it breaks, it may never break on you. It breaks on some users, on some datasets but not always. No clue why. So, I went back and changed the code that could be flaky, the logical side of when to set the stop losses. This shouldn't matter, but I noticed that the mode3 SL weren't being modified when they should either. Rather than obsess over the bug I couldn't find, I fixed the bug I could find. At the same time, it fixed the bug I couldn't find. Old hat programmer tactic.

Since Mode3 in 5.6.* never worked right, I'd recommend going to 5.7.0 if you want to test Mode3. If you want to see how well the bugs perform, you can optimize for bugs in 5.6.8 fairly well and 5.6.3 fairly well. Neither version "works as intended" but the bugs are much less frequent and less trading errors than other versions.

Bertbin and Vince, if you want less SL=Breakeven action, you can emulate the trading style of previous versions by not using much SL movement. If Trade3 has the lowest TP, then only Trade2 will have SL=BE. Strange, esoteric, but that is working as intended and would let you play with Mode3 in a way that has similar functionality to previous versions. More variables = more ways to tinker, but the defaults should work fine.

Mode1 has been the same throughout the entire 5.6.x and 5.7.0 with the exception of adding signal_count.

 
 

Ordersend(130) Error in v5.7

Hi all,

I encountered an error (Ordersend (130)) while backtesting version 5.7, Mode 1, on 15M Eur/Usd from 10/12/2006 until 19/12/2006. Take a look at the screenshot.

-RJ1-

Files:
Reason: