Good idea that should suit everyone.

I will go through and verify this soon, I want to make sure each signal is accurate and correct the copy paste errors.

I have a todo list now, in no particular order. Anyone, feel free to join in.
Verify Signal interpretation from PContour
Tweak signal trade data in P6 Beta1
Create stealth trading system that is TS compatible
Combine "sliding" and "contracting" trailing stop systems.
Write P6 Simple and Advanced documentation
Wire transfer (attempt 3, now that the bank and fxdd agree on account name) money to PhoenixFund
Write up the guide on optimization I worked out with hhsmoney. (I can email edited logs if anyone is interested but I think I need to rewrite a lot of it)
Troubleshoot Chimera Signals.
Analyze signal 4 RSI declining signal in backtest
Optimize currencies (hhsmoney has USDJPY grinding at the moment)
Test long term validity of trend filter, test performance of Gann Style S&R lines. (Both are in P6 Adv Beta1 already)
Do calculations on time-to-reversal, either Elliot Wave style, or magnitude+timing (suspect 25-40% of reversals come at regular times or regular intervals)
Website for PhoenixFund needs updating
Create a single archive of all settings files created. Group them by Number for signal optimization, Group them by letter for changes to risk, trailing stops, modes, etc.

I was distracted by TF and life this weekend, I think we need to step up performance on P6 :/

Edit:
Confirm Grace/Force code
Confirm ParaSAR TS

I've tested this ATR-ratio indicator in other EAs and have found it to be fairly good at avoiding entry in a narrow ranging market. In my tests, it improved win/loss ratio. Accomplished by avoiding ranging market entry about 80%.

It takes ratio of two ATR scans, 1 short - 1 long, and then compares this value to a stationary threshold limit. If ATR difference is above threshold limit, then trades are allowed. If below, no trades.

if atr2 > atr1 then order entry OK.

Wackena

Attached Images

usdjpy=m30-atr.gif (15.2 KB, 238 views)

Attached Files

ATR ratio.mq4 (2.3 KB, 73 views)

I observed a lot of Phoenix signals and I think it would be interesting to place delayed orders with Buy Limit/Sell Limit instead of market orders. Most of the times, phoenix takes a position that goes up and down a few times before really enters into the profit zone. Let say it place an order 5 or X (outside settings) pips lower on a buy signal. Most of the time, it will take the trade anyway so we could have 5 pips more if TP and 5 pips less in case of a loosing trade. I would leave the TP and SL the same as if it would have opened at the signal time.

What do you guys thinks ?
Is it difficult to code ?

__________________
"A discovery is said to be an accident meeting a prepared mind." Albert Szent-Gyorgyi

It sounds good. Lets see if it will really make money, providing I can code it. Not every idea is compatible with the existing code.
I added it to my list of things to do.
I think it might be easy, but I am not sure. I will email you some code hopefully based on P_5.7.3, and let you validate it. I put your idea fourth on my list.

Thank you very much PContour. I appreciate your help and will test it hard when available.

__________________
"A discovery is said to be an accident meeting a prepared mind." Albert Szent-Gyorgyi

M6M6: It is very compatible with Phoenix 6, suggestions like that are 100x easier to implement in P6 than in P5.

Wackena: I'll implement it in P6 Beta 3 to be released this weekend. I'm still playing around with signals and optimization. I'm going to add a different RSI as well, so we can have a few signals to choose from and then set up different "trading methodologies" all in a single code base. (Only difference between Trend and Countertrend will be signal input)

I don't like moving averages in general, and here is something experts have to say, from "Encylopedia of Trading Strategies" page 110:
While Phoenix6 appears to nail the cusp of a change in the USDCHF settings, it doesn't appear to pick the direction well. It could simply be that the settings need to have a reduced profit and use trailing stops.

The themes for the next release. Improve default values, and provide error translation.

• I'm planning to make up a piece of code to translate the meaning of the err numbers. This should help clear up misguided beliefs and instill some truth. It's also going to save everyone time so they don't need to go look them up themselves. Since the trade has been blown, there should be a moment or two available to spit out a error code translation.

The following has been completed.

1. Extra debug information to help with problems
2. Change default decrease factor to 901010
3. Change default minlot to 0 to kick in my new fix to prevent lot size problems.

No change to the settings file for 5.7.4.

No. I have no planned date.

I recommend that you change your settings file to the default values as mentioned in step 2 and 3 above in version 5.7.3. It would reduce the number of errors you should see.

I have an idea for lot management, and I haven't seen it elsewhere. If anyone knows of code that does this, I'd love to see it and possibly reuse it. I'm working on this because it is too easy to destroy an account using common methods for lot sizing by simply choosing too many currency pairs.

The "risk" of a trade has nothing to do at all with the margin or balance, but we give it that name and appearance in the EA.

The "risk" of a trade is the amount of money on the table, not the amount of margin on the table. Let's say I'm willing to loose $500 on a single trade. How do I calculate lot sizes for that? How do I determine the SL level? If we have SL, we assign lots based on $/pip*SL*lot=risk. If (user) risk is $500 and SL is 50 pips and the $/pip = $10 then we know lot=1. Now we have a bit of an issue, because the lotsize determines the $/pip. If $/pip=1, then we would have 10 lots which then makes each pip worth $10. It is a circular situation, and what we really need is dollars per pip per lot or $/pip/lot=10 or we phrase the entire thing in the basic unit, the pip.

Instead of saying how many $ we risk, we can choose how many pips we risk, in full lot sizes. This also removes the need to calculate how much each pip would be worth. If I'm willing to risk 100 "full lot pips" on a trade (or $1000 on EURUSD), and the SL is 50, then that would mean I'm willing to risk 2 lots. That becomes $20 per pip. With a SL of 50 and $20 per pip, that is $1000. Since pips are usually about $10 per trade, this isn't that strange. However, some currencies like USDMXN or USDNOK get a little strange on the math. GBPJPY is also strange on the math, and the conversion would need to be known.

So we have two options. #1 Recalculate the $ per pip per full lot, and then convert the math over to determine lotsize. #2 Determine the lot size purely from SL and max pips lost. Unfortunately, expressing things in pips might become confusing and for all currency pairs where the second currency is not USD the pip math gets confusing for the user.

Now, there is another issue. Margin. We need the FreeMargin to stay open. Using the current system (FreeMargin/ multiplier_for_sanity* some_number_which_pretends_to_be_risk) we have free margin open, but a long term trade could easily destroy the account even with small lotsize. (1000 pips SL) If we are doing $ at risk per trade, then the FreeMargin needs to stay open, but we *know* mathematically that the account won't go bust. If we have a minimum margin value preserved in dollars, then we would avoid the bottom line. Unfortunately, this isn't compatible with the way brokers do the math. They calculate margin by %. Many brokers will start closing trades at around 50% or 75%. I have never heard of a trader on here recommending risking more than a small % of the overall account per trade. I would think that the FreeMargin% should always stay above 100% (In other words, fully leveraged but I would only use this math if we're calculating the maximum risk in real dollars per trade.)

Unfortunately there isn't a direct simple calculation we can do to predict the total margin potential. We could have a fixed ($$) or dynamic (% of All $$) system that is protected from loss in trade.

Ultimately the system for risk allocation should be safe for multiple systems to trade with.