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

 

insert funtiocn

hi daraknor,

in post #2, you display function "void CheckForClose() ".

This function must be introduced to phoenix 5_06_04 to decrease drawdown !

i 've downloaded the last version in post#1, but it is not.

giapel

 

API-Call checking

hi daraknor,

thank you and the others for your work. I've tested Phoenix_5_6_04 with

MIG - Trading Metatrader and most of the time i get OrderModify Errors 130.

The Errors occur in Mode3_MoveSL_Trade_3() function. I think the reason is that

SL is greater OrderOpenPrice() in a Long order and vicaversa in a Short order.

It seems that the EA code is not fully checked if API Errors happen.

I think we should introduce API call checking for each API call and evaluate

GetLastError() if possible. This would make Phoenix more reliable.

regards

 

TrailingStopChecking

another bugy code seems to be:

if(PhoenixMode==1)//Phoenix Classic

{

CheckOpenTrade();

if(CloseAfterHours != 0) CheckCloseAfterHours();

if(!StopLoss==0) CheckTrailingStop();

if(BreakEvenAfterPips != 0) CheckBreakEven();

}[/PHP]

so even if TrailingStop is 0 CheckTrailingStop() will be executed

and if(OrderType() == OP_SELL) the Order can be modified without serious reason because (Point * TrailingStop) == 0.

maybe its better to change to:

[PHP] if(PhoenixMode==1)//Phoenix Classic

{

CheckOpenTrade();

if(CloseAfterHours != 0) CheckCloseAfterHours();

if(TrailingStop !=0) CheckTrailingStop();

if(BreakEvenAfterPips != 0) CheckBreakEven();

}

regards

 

To pip'er

To pip'er

Yes, that is the idea. The point is that there are two outcomes after Phoenix has opened position - SL or TP. Sometimes, TP is reached in 2 hours after opening position. Sometimes position is held for 3 days, while price fluctuates around brakeven point (entry point). So we just get additional profit. The closer to SL of the first position we enter, the better is gain\loss ratio. I'm going to becktest this idea manually.

Concerning counting signals before entering position, I believe it does not improve Phoenix performance, and my backtests prove that. I guess that Phoenix is specially programmed to ''swallow'' or ignore other signals after entering position, like opening in other direction. Once position is opened there are two outcomes, and we should just wait. However, most positions made by Phoenix are correct, and before hitting TP, price fluctuates, that we can use. Simply just entering when we have -50 pips on first position, there is high probsbility, that the price will AT LEAST AGAIN reach entering point or breakeven point. So we enter with stoploss 30 pips ( Stoploss point of the first position) and takeprofit +50pips (entry point). So gain\loss ratio is much better than with initial TP 42pips and SL 84 pips.

 
giapel:
hi daraknor,

in post #2, you display function "void CheckForClose() ".

This function must be introduced to phoenix 5_06_04 to decrease drawdown !

i 've downloaded the last version in post#1, but it is not.

giapel

The only change to the default behavior in 5.6.04 was a Hendrick approved fix for mode 3 written by HerbertH that he promised us. The code in Post #2 are varied submissions written on the old forum thread, collected by several people, and sent as an attachment to my email address. I posted them here so we can all look at them easily, and I can collect valuable feedback like your comments here

I will try to include it in the next experimental build (and I plan on at least 1 release per week). I consider this change to be "altering the logic of Phoenix" and not a pure "bug fix". Does this make sense?

My main "development goal" for releases is to come up with a "Stable" version of Phoenix even though it might not be as profitable as an "Experimental" build. Some people will probably run experimental builds on real data. I supported a company at a datacenter who had 20 machines with custom kernels running the 2.3.30-50 builds of the linux kernel. He wanted the features, he ran experimental code.

5.6.4 is intended to be a "stable" candidate. I will release experimental nightly builds while we work on a stable build - so both types of users will have the kind of code they want to run.

 
Trader83:
To pip'er Yes, that is the idea. The point is that there are two outcomes after Phoenix has opened position - SL or TP. Sometimes, TP is reached in 2 hours after opening position. Sometimes position is held for 3 days, while price fluctuates around brakeven point (entry point). So we just get additional profit. The closer to SL of the first position we enter, the better is gain\loss ratio. I'm going to becktest this idea manually.

Short Version: Try MaxTrades=3 signal_count = 10 and variations of similar settings.

Long Version: I'm glad people are very interested in this. To perform a very similar test you can also set MaxTrades = 2 or more. That way if you are in a buy trade and you get a sell signal, you enter the second position. It is highly recommended to have signal_count set to ?? value so you don't enter the same signal each tick up to the maximum value. (see "Weekly build notes" in this thread) It may be better to use "confirming signals per bar" instead of "confirming signals per tick" when combined with MaxTrades. Please see the links in this thread, the code change to do this is moving one line of code 4 or 5 lines higher.

 

Denkhaus: Thank you very much for reviewing the Trailing Stop code. I submitted it as it was sent to me. I will review this entire code block possibly do something different. I made a thread just about Trailing Stop strategies, and I currently have 10 different strategies that can be done with them. I will probably incorporate some of my other code into Phoenix to make TrailingStop and breakeven code work as closely as I can get it to "intended" but "bugfree".

 

Request

Would be to difficult to ask that each code post be identified beginning line number so that those who wish to learn the process can see the code in its context and cut down on search time (12 pages printed) since you may not know exactly where to look as a learner. No need to respond just a request if you think of it.

Greg

 

I recommend using SciTE text editor. It works on windows, linux, etc. If you turn on "C" style syntax highlighting you get many features like syntax checking. It has code collapsing so you can shrink functions, tabs so you can compare multiple files, if you move cursor near a } it shows the matching {, very advanced find/replace options etc. It doesn't have the lookup tools that you get using MetaEditor of course, but you don't need those at all if you are just reading text. I tend to use SciTE when I develop Python and PHP, but I have specialized IDE for C/C++. The more familiar you are with MQL functions, the more reason to use SciTE over MetaEditor for development. For code review I always recommend SciTE. I am working on a code cleanup/optimization project now, and I think SciTE saved me several hours of checking curly braces, etc. Only feature I want out of Visual Studio that isn't present in SciTE is auto re-indent (find a blob of unintended code and auto indent every line).

http://www.scintilla.org for download (free software). If anyone else knows of a free lightweight text editor with auto-reindent and code collapsing, please let me know

For matching code with code to replace, I recommend find. For printing out line numbers on several pages of code, I have no idea except possibly in whatever program you use to print. I think SciTE can do that but I'm allergic to printing. Actually I need a new ink cartridge but that's more personal.

 
Short Version: Try MaxTrades=3 signal_count = 10 and variations of similar settings. Long Version: I'm glad people are very interested in this. To perform a very similar test you can also set MaxTrades = 2 or more. That way if you are in a buy trade and you get a sell signal, you enter the second position. It is highly recommended to have signal_count set to ?? value so you don't enter the same signal each tick up to the maximum value. (see "Weekly build notes" in this thread) It may be better to use "confirming signals per bar" instead of "confirming signals per tick" when combined with MaxTrades. Please see the links in this thread, the code change to do this is moving one line of code 4 or 5 lines higher.

There can be no signal for entering second position after Phoenix opened first position. That is why I propose to enter second position not by signal, but by distance from the entering point of the first Phoenix position. This second enter should be made between Phoenix SL point and Phoenix Enter point. The closer to SL, the less will be Stoploss of second position, the greater will Takeprofit (distance from entering second position and Breakeven point of first Phoenix position). Simply by having good gain\profit ration we'll get profit.

The only thing is that what is the probability if the price goes -40pips, then returns to breakeven (and goes to Phoenix TP). It is very timeconsuming to test it manually, so it would be great if somenody could add to code of Phoenix several options:

- to enter second ''not Phoenix'' trade when prices goes to -X pips

- SL of that second trade is the same as Phoenix position one

- Take profit - variable (usually - entering price of Phoenix position)

- ability to decrease number of that second trades (as ptice can fluctuates a lot, and btw we can get 2 or 3 trades while holding Phoenix position)

On the whole, this idea is based not on signals, but on statistics, that Phoenix makes a lot of correct entries, which overcome bad entries. Plus, goog gain\loss ratio.

Reason: