Settings File Conversion - New people don't need to convert settings files.

Conversion and Instruction are contained in each zip file. (see attachments - below)

• phoenix 5.7.1.Convert.zip is for 5.7.0 to 5.7.1 conversion
• phoenix 5.7.2.Convert.zip is for 5.7.1 to 5.7.2 conversion - good for 5.7.3 and 5.7.4 also

Pref Settings Summary by alamanjani (see attachments - below)

Quick Summary of what currencies are supported with Preferred Settings and the values for Phoenix 5.7.2, 5.7.3 etc.


Take this Hyperlink to Phoenix 5.7.4 - I consider this to be The Best Version of Phoenix

Decrease Factor

2.. I have updated the Money Management code . By setting setting U_MM to true and U_DecreaseFactor to a six digit number here is what happens. example U_DecreaseFactor 901010

If in the last 3 trades you have

• 0 losses you get 100% of your expected lots
• 1 losses you get 90% of your expected lots
• 2 losses you get 10% of your expected lots
• 3 losses you get 10% of your expected lots

Previously decrease factor was useless.

The way to use the decrease factor is, after all the optimization is done, turn on this setting for live testing and run a live test with the decrease factor on and a live test with the decrease factor off.

Mode 1 Trailing Stop

Changed the Trailing Stop MODE 1 ONLY so that if you set it, it will override the pref settings, and change the Take Profit to 999. This changed the profit on my 2 month back test from 2823 to 4008 almost 42%. Now with a configurable shrinking Trailing Stop. You use the field P_M3_CloseTrade_23, the trailing stop will shrink by 1 for every P_M3_CloseTrade_23 points into the profit that you position move. Set it to 5 and if you are 45 points in profit the TS is changed to 45 - (45/5) = 36. My little sample improved to 4094, another 3%. Best value in my optimization was any value over 65. Why shrink the TS? So that the more points you go into the profit the less pips you leave on the table.

Three updates to the above strategy

1. Make it kick in at one point in profit.
2. Make a TP an equal number of pips above current price as TS is below point. TP and TS both move up and then never retreat. This is so that if your computer loses it's connection to your broker,the trade will close itself once it hits the TS or the TP.
3. Make sure that the SL or TS is not too tight to make the trade illegal.

The result don't look as good with these additional settings in my tests, but as Daraknor points out backtesting is sometimes not realistic.

Phoenix Documentation 5.7.4

Attached below


My Home Page in my Browser. Phoenix Fanatics will want it, and new people really need it.


Some Great Tools

freeCommander

Attached Files

	phoenix 5.7.1.Convert.zip (45.9 KB, 319 views)
	phoenix 5.7.2.Convert.zip (46.2 KB, 448 views)
	Phoenix_5_7_2_original_preffered_settings.zip (4.5 KB, 221 views)
	The Ultimate Guide for Phoenix 5.7.4.doc (379.0 KB, 237 views)
	How to optimize Phoenix_5.7.4.doc (225.0 KB, 206 views)

I released 5.7.2 with no further changes. Sorry about delay due to illness.

What is the reason for converting Phoenix 5.7.2. and how is it accomplished? Also has anyone addressed number of lots/equity on a mini? I would be interested in code for Phoenix that would divide equity by $500 and trade the resulting number in mini lots. We have it in MT3, but not MT4. Thanks, Les.

Would like to know if the attached file is a proper conversion for 5.7.2a when you have time. Thanks, Les

Attached Files

Phoenix_EA_v5_7_2aCov.mq4 (53.3 KB, 81 views)

Am getting Fast Length/Slow Length Alerts when loading Phoenix 5.7.2aCov on charts. Does that mean that numerical values under currency pairs need to be changed? See attachment. Thanks for your help, Les

Attached Files

Phoenix 5.7.2aCov Alerts when loading.doc (59.0 KB, 71 views)

A simple formula is used to calculate the lot size. MaxRisk can adjust the size of each lot. It is currently based on FreeMargin() but can be altered to AccountBalance() by changing that one name.

Phoenix 5.7.2W allows settings where "fast is slower than slow." If you look at the settings you will notice that Fast has a larger value than Slow. this is a logical error, and will lead to long term erratic trading. I recommend reoptimizing the fast and slow values under 5.7.2a. My optimization notes have more information on which values are valid and which are good examples.

2 out of the 6 preferred settings in the program were set as "fast is slower than slow". Perhaps the signals work better when they are not correct . I'll post my Phoenix 5.7.2W code in this converts thread.

.............................EURUSD USDJPY EURJPY GBPJPY USDCHF GBPUSD
Signal4
P_Fast_Period= ......... 4......... 25....... 20....... 17....... 5......... 25
P_Slow_Period= ........15......... 15....... 10....... 28....... 20....... 37

I don't doubt that some high performers were found with "fast is slower than slow" settings and that they work. USDJPY has some decent performance with this flawed setting. My point was that other settings also exist, and they are both correct and perform well. They may also be more reliable, but only time will tell.

Happy Day: PhoenixFund was approved as an FXDD IB. See PhoenixFund thread for details.

I agree, decrease factor wasn't working properly and was useless. I hadn't played with it or decided on how I wanted to fix it. I saw what the code was *intended* to do, and wasn't sure it was a good idea. Can we have a DecreaseFactor that is used as a percentage? Something like this:
DecreaseFactor=50

• 0 loss=100% lotsize
• 1 loss = 50% lotsize
• 2 loss = 25% lotsize

DecreaseFactor=10

• 0 loss = 100% lotsize
• 1 loss = 90% lotsize
• 2 loss = 81% lotsize

A value of 100 would stop trading immediately after a loss. Since there isn't a massively increasing lotsize based on wins (only balance changes) a massive DecreaseFactor may not be a good idea. Having a configurable value seems important to me.

Also keep in mind that some brokers round off decimals. A 0.9 lot becomes 0 lot I believe. We need to make the lotsizes decimal safe (I think Phoenix has a global decimal tracking system but I don't remember.)

If we can get something like this, I think that would be worthy of a new release. I was also considering email/screen alerts after 2 consecutive losses.

I came up with those numbers by optimizing. Well not the traditional way. I would allow for 3 factors to be used. We could put it into one string (My settings would have been 802000). Or 3 strings of 2. Your percentage Idea, I find too limiting. I actually tried formulas similar to yours. Things that felt mathematically good and symmetrical in some way. They didn't give the kind of results I wanted. I just stumbled upon the best result. I wanted to float the idea to see if it was any good. I think 3 strings of 2, would lead to best optimization.

The best formula I came across indicates. 1 loss is nothing. 2 losses is a warning, things are deadly ahead, 3 losses stay out totally.

On your other point about partial lots. I think you said If you are trading mode 3 then you should use a micro account so it will use partial lots.

So lets find some common ground and I'll send you some code. I'm not so sure about how to make things lot safe.