Phoenix Setting File Converters
I released 5.7.2 with no further changes. Sorry about delay due to illness.
Conversion of Phoenix 5.7.2
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.
Phoenix 5.7.2a conversion
Would like to know if the attached file is a proper conversion for 5.7.2a when you have time. Thanks, Les
Phoenix 5.7.2aCov Alerts
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
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.
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.
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.
2out 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.
2.. I have updated the Money Management code in this W version. By setting setting U_MM to true and the decrease factor to any number greater that zero here is what happens.
If in the last 3 trades you have
- 0 losses you get 100% of your expected lots
- 1 losses you get 80% of your expected lots
- 2 losses you get 20% of your expected lots
- 3 losses you get .01% of your expected lots
Previously decrease factor was useless.
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
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.
The settings you mention do make sense. I had to think about it, but it is more logical than algorithmic. The logic is very sound, but I do request we round up the last trade to the minimum lot size. With a 1 lot trade to start, a 0.1 lotsize is a common minimum and 0.01 won't work at all.
Great, I will provide the code with 3 new variables soon. I would ask you to fix any lotsize issues, as this is not within my understanding yet, or send me a function to use. I actually used the following code where MinLot I believe comes from Dmitry_CH Add 5.7.1. Dmitry code to fix minlot/maxlot may do the job we need for this already.
if (losses==0){ lot=lot*100/100; }if (losses==1){ lot=lot*80/100; }
if (losses==2){ lot=lot*20/100; }
if (losses>=3){ lot=U_MinLot; }
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
Conversion and Instruction are contained in each zip file. (see attachments - below)
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
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 strategyThe 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