Reading this when I'm awake helps a lot. That does make sense but knowing what "usually" is would be important. Maybe set a SL=breakeven once you hit 5 pip profit too. Adding trades like this sounds like a fun thing to do for Phoenix 6 candidates, trying out new code.

Right now my main interest is simply making Phoenix more reliable and robust. I will put this on my list of things to write. If someone else wants to write it in the meantime, sounds great. Having a few experiments sitting around would be entertaining to programmers I think.

The irregularity in trading with the same broker, same data, same settings, same timeframe, same ... everything is my main concern. Sometimes 2 installations stay in sync, sometimes they trade with opposite signals. (Billworld2 live testing, trading results in old thread, my results I need to post) I am hoping that the consecutive trade filter will help filter reverse results.

Since the indicators are based on the differences between values (moving average, etc), a small difference would yield a trade. The size of the values aren't checked, just their relative value. If the values aren't very strong one way or another, they may bounce back and forth quickly. A filter has been added in the 5.6.4 (you need to modify settings to activate it) to not trade on changing signals.

(Signal 4 is custom)

There are three additional consequences I forsee with the filters. 1) trades will be slightly delayed, which will have a the configured number of ticks delay before a trade is entered. This ultimately means less drawdown but too large of a value may miss a trade. 2) No wavering between values where the indicators don't offer strong conclusions. 3) The signal threshold also acts as a time filter. The current version is tick based (which I like) and a fix was submitted to make it time based (which may not respond to high volatility in time to trade). Adding time filters also enables us to add multiple simultaneous trades.

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

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

another bugy code seems to be:


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:


regards

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.

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.

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".

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