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

 

AutumnLeaves, please email me the code for EASY so I have your email address.

 

In Phoenix 5.7.2 I could not confirm this bug. It appears your Phoenix modified version has an issue where the code doesn't confirm the new SL is an improvement over the old SL. The code in 5.7.2 is working properly. I'm working on porting EASY over to Phoenix6.

 

Phoenix signal 1

As I mentioned in another post, the Envelope signal (#1) in Phoenix is problematic. Please compare the attached figures. You will see that with the default setting for GBPUSD, the band produced by the Envelope signal is barely better than a line. There is only up and down, and no in between. The object of the Envelope signal is to create a no trade channel, not a single line dividing buys from sells.

With a more realistic setting (0.025-we ignore the period for the time being) you get a nice band which has an interesting property. It widens when the price line is oscillating (i.e., flat) to prevent any trades (since trades only occur above or below the band) and tightens up when the curve is trending up or down in order to open up trade possibilities.

This function is essentially the same as the Price Action Channel, although the latter may have some advantage over the simple Envelope indicator. Price Action Channel uses a calculated average price (a la Heiken Ashi) which may better reflect the movement of the currency than the simple High and Low we have been using with the Envelope signal. It might make sense to replace Envelope with Price Action Channel, although Envelope may offer some advantage. Because it is not a smoothed average, it follows the curve better at the top and bottom of a trend slope. Accordingly it might help filter out trades when the curve is exhausting itself and about to reverse.

Of course here I am speaking in terms of a trending system. For the time being, I will keep using both until it becomes apparent that one of them is not serving any purpose.

 
daraknor:

I'm just a stooopid noob and all, but if I have an EA that uses 2 settings to decide when to enter a trade, and it is profitable long term on valid history data 100% of the time if the two settings are more than 10% apart but still within valid range, is that a holy grail?

ALL valid settings are profitable on some currencies, and it can trade with more settings on nearly any currency. It can do 3 trades per year (per currency) or 2000 trades per year (per currency) and do them both profitably. (Change 1 number).

Is ... that a holy grail?

Wau! I have no words to describe, how I become without words

Result are really really great!

Pass 200, over 24.5 pips per trade with less than 8.5% drawdown?!?

Or pass 115 with 17 pips per trade with only 6.65% drawdown!!!

This is impressive! This sound something like cash machine...

daraknor:

Adding the guts of a very promising EA to P6 for free isn't something I'm sure I'm ready to do.

I understand you completely. Hope this EA helps you reach your dreams. You deserve it!

Good work!

Mario

 

I just finished writing some insights from my studies of the fractals into Phoenix. I didn't add the fractals, I added the emergent property that often matches the fractals. The emergent system is based on Gann's observations back in 1910 of commodities and stocks for determining Support and Resist levels. Gann's work was extended by others over the years, and then I finally made it work with forex. I checked a few days of data, and it lines up with the fractals about 90% of the time. However, the fractals are a much more complete picture than Gann's way of calculating data and Gann's method doesn't work for substantial price movements whereas the fractals do.

alamanjani, you should have received a copy of the demo code, please let me know what you think of it. Some data sources it just can't loose money no matter what crazy settings I use. Other data sources and it looks confused. :/

 

Phoenix 6, Beta Advanced and Simple has been released in a new thread.

 
daraknor:
In Phoenix 5.7.2 I could not confirm this bug. It appears your Phoenix modified version has an issue where the code doesn't confirm the new SL is an improvement over the old SL. The code in 5.7.2 is working properly. I'm working on porting EASY over to Phoenix6.

I confirmed this bug and updated. It was my misuse of Mode_Stop.

You may not have used this part of my StopLoss code.

 

Code Fix

Daraknor

I got errors from the following code because I didn't set the MinLot to the right value.

if(lot<U_MinLot) { lot=U_MinLot; Print("lots switched to min ",lot); } //Dmitry_CH Add 5.7.1

if(lot>U_MaxLot) { lot=U_MaxLot; Print("lots switched to max ",lot); } //Dmitry_CH Add 5.7.1

I did it in the following way,so I would not have to set these variables myself, and it worked.

Add this to the init section.

U_MinLot = MarketInfo(Symbol(),MODE_MINLOT);

U_MaxLot = MarketInfo(Symbol(),MODE_MAXLOT);

This information is entered, by the currency for each broker.

I just kept the extern variables as they are so there would be no change to the settings files.

I created a 5_7_3 version of the code, which I will publish tomorrow.

 

5.7.3 sounds great, it would be nice to have a new maintenance release.

We can use the MinLot/MaxLot settings from broker if the value is zero, but it would also be nice to give people the option of a manual override. Something like:

if(U_MinLot==0) U_MinLot = MarketInfo(Symbol(),MODE_MINLOT);

if(U_MaxLot==0) U_MaxLot = MarketInfo(Symbol(),MODE_MAXLOT);

 
daraknor:
5.7.3 sounds great, it would be nice to have a new maintenance release.

We can use the MinLot/MaxLot settings from broker if the value is zero, but it would also be nice to give people the option of a manual override. Something like:

if(U_MinLot==0) U_MinLot = MarketInfo(Symbol(),MODE_MINLOT);

if(U_MaxLot==0) U_MaxLot = MarketInfo(Symbol(),MODE_MAXLOT);

Good idea that should suit everyone.

Reason: