PacMan (my first hybrid) - page 8
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
...
I did a back test with out money flow index(MFI) and was 60%. I did one with MFI filter, and got 65%.
I have alot of ideas for signal accuracy, and will take a while to test them all. My goal is to have 70% or better accuracy on signals.
...I am happy if you concentrate on the signal side, since my knowledge there is limited. I am better at trying to squeeze more out of your signals ...
TrailingStops are now compatible with multiple trades. I need to do some work on RecrossMax to make it multitrade safe, hopefully without reading the chart every tick or bar. :/ If you set the value for MoveTPonTS in P6 alpha4 to 0, then the TP doesn't move at all. Setting it to 1 allows the TP and SL to be fairly evenly set. Gaps up a little bit will slowly bring the SL closer to TP. News events will likely hit the TP. Setting it to 3 or 5 makes sense to stay ahead of news events, but so would disabling TP completely (setting it to zero uses the current value. :/ ) The reason for moving the TP is so you can have a higher average profit, instead of an average profit ranging from DelayTS-TS to TP (usually in the middle) the average profit can be several times higher than the TP.
It seems we should have a closer look at your way of handling TrailingStops. My first tests showed lowered average profit in return for occasional higher profits, so I abandoned using TrailingStops. If there is a way of using TrailingStops to increase average profit per trade, I am definitively interested again.
Getting this error:
2007.03.22 12:55:59 '9009430': order sell 0.02 EURAUD opening at 1.6526 sl: 0.0000 tp: 1.6503 failed [Trade is disabled]
Something I'm doing wrong?
Thanksthe "Trade is disabled" message is one from your broker and has nothing to do with the EA.
You are probably using Velocityfx mt4 platform and they at the moment have liquidity problems with certain pairs.
See the message below which Velocity sent out to some people:
Velocity4x
March 21, 2007
Due to a technical issue with our liquidity providers we will be limiting trading on select currency pairs to a close position only setting
If there any pending orders in these pairs these orders will be canceled until this issue is resolved. We are working as quickly as possible to resolve this issue and will notify you when full trading is again available in the following pairs:
AUDUSD
AUDCAD
AUDCHF
AUDNZD
EURAUD
GBPAUD
NZDJPY
NZDUSD
USDMXN
USDNOK
USDSEK
AUD/JPY
EUR/NZD
NZD/CAD
NZD/CHF
GBP/NZD
USD/ZAR
We are working to resolve this issue and appreciate your patience and understanding in this matter.
Sincerely,
The Velocity4x Team
I am happy if you concentrate on the signal side, since my knowledge there is limited. I am better at trying to squeeze more out of your signals ...
Deal
Here are 2 back tests with money flow index, volume, and volitity indicators.
I have one set with equity target to take me out at 8 pips and one at 6 pips. Thats on the initial 1st order. If 2 orders are open 6 pips will become 8, and 8 pips will become 10, and as more open against me the point that equity target becomes greater. So the actual tp is my equity target and the space between the equity target and the hard tp is there if needed. This lets me have a small target that has a high % win, and still maintain a large enough pip step to accomidate the market. There was 3 points of draw down hell in 4 months. 1 small. 1 rather large. And one average. With 2% risk these floating p/l would scare even me.
I would like to work the win % above 80% with out going below a 8 pip equity target. the 6 pip target was 1% more accurate but made slightly less money.
Dave
the "Trade is disabled" message is one from your broker and has nothing to do with the EA.
You are probably using Velocityfx mt4 platform and they at the moment have liquidity problems with certain pairs.
See the message below which Velocity sent out to some people:
Velocity4x
March 21, 2007
Due to a technical issue with our liquidity providers we will be limiting trading on select currency pairs to a close position only setting
If there any pending orders in these pairs these orders will be canceled until this issue is resolved. We are working as quickly as possible to resolve this issue and will notify you when full trading is again available in the following pairs:
AUDUSD
AUDCAD
AUDCHF
AUDNZD
EURAUD
GBPAUD
NZDJPY
NZDUSD
USDMXN
USDNOK
USDSEK
AUD/JPY
EUR/NZD
NZD/CAD
NZD/CHF
GBP/NZD
USD/ZAR
We are working to resolve this issue and appreciate your patience and understanding in this matter.
Sincerely,
The Velocity4x TeamI got the message too. Puts a slow down in my live trading. Stinks. I hope they do get this resolved quickly as everyday they are down makes it tempting to go with MIG as a broker.
Velocity4x is a whitelabel company. I called them and asked a bunch of questions. They share a liquidity pool with IBFX, FXLQ and FXSOL although they did not state so explicitly (vague references to a 3 member exchange, "our bank", and other crap identical to crap fed by the parties mentioned.)
MiG has a very erratic signal from what I saw scanning their charts. We did live testing for Phoenix on several brokers, and FXDD almost always was the top performer. The second in line, occasionally first, was NF. I researched FXDD extensively, but not have done so for NF. PhoenixFund (a nonprofit that funds UN Development Program goals with EA trading proceeds) is now (finally) an IB for FXDD after months of work. (We did testing first, and then went with the winner.)
As for trailing stops, I have had long term 'average wins' several times higher than my TP thanks to tight delayed super-increasing trailing stops. (Eat those news events!) The trailing stop code was developed with the idea that we shouldn't leave pips on the table. Phoenix beta is getting a code cleaning/review from a fellow developer, here is the latest trailing stop code:
extern int staticTS =20;
extern bool MoveTPonTS=1; //increase Trailing stop by this value in pips each time TS is adjusted. Allows good trades to rise higher
extern int U_DelayTS=0;
//Every Tick, during order processing:
if (ExitManagedOn) trailingStop(myticket,staticTS,U_DelayTS);
void trailingStop (int ticket, int tsvalue, int delayts)
{ //TS Function, easily called by multiple exit strategies.
double slvalue;
Debug("EXIT:TS ticket:"+ticket+" tsvalue:"+tsvalue+" delayts:"+delayts);
if (OrderType() == OP_BUY)
{
slvalue=Bid-(Point*tsvalue);
if (OrderStopLoss() < slvalue && OrderOpenPrice()+Point*delayts<Bid+tsvalue*Point)
{
//Debug("OrderSL:" +OrderStopLoss()+ " slvalue:"+ slvalue);
if (!ModifySL(slvalue,ticket)) LogError();
}
} else {
if (OrderType() == OP_SELL)
{
slvalue=Ask+(Point*tsvalue);
if (OrderStopLoss() > slvalue && OrderOpenPrice()-Point*delayts>Ask-tsvalue*Point)
{
//Debug("OrderSL:" +OrderStopLoss()+ " slvalue:"+ slvalue);
ModifySL(slvalue,ticket);
}
}
}
}
bool ModifySL(double sl, int ticket)
{ //Moving SL function, easily called by other exit strategies.
int MoveTP;
if (OrderType() == OP_SELL) MoveTP=MoveTPonTS*(-1);
else MoveTP=MoveTPonTS;
Debug("MODIFY Ticket:"+ticket+" OpenPrice:"+OrderOpenPrice()+" SL:"+sl+" TP:"+(OrderTakeProfit()+MoveTP*Point));
if(OrderModify(ticket,OrderOpenPrice(),sl,OrderTakeProfit()+MoveTP*Point,0,Red)!=(-1)) LogError();
}
...
As for trailing stops, I have had long term 'average wins' several times higher than my TP thanks to tight delayed super-increasing trailing stops. (Eat those news events!) The trailing stop code was developed with the idea that we shouldn't leave pips on the table. Phoenix beta is getting a code cleaning/review from a fellow developer, here is the latest trailing stop code:
...Sounds encouraging, I will study the usage of trailing stops again, thanks for your insight.
When I find time, I will refactor the Goblin Bipolar code to modularize it and make individual functions more flexible. For some of my ideas it becomes increasingly complex to build everything into the current kernel, which mixes order management with other things.
...No matter how many times you do it, random entry = loss. If you delay the pyramid/martingale until you have a reason to enter the larger trades *and* you have a reason to enter at that time, then you have a solid system.
So if you have PF(Signal)=1.2 and you do this for each loop:
PF(Loop[1])=1.2
PF(Loop[2])=1.2
PF(Loop[3])=1.2
PF(Loop[4])=1.2
Then your chance of earning a profit on each loop increases dramatically. I'd calculate the odds, but I don't have time to do a Bayesian series before the bank closes.... must run.Ok, I see that the next thing I need to build into my statistics function is to actually measure the edge at every level. On this basis it becomes easier to compare entry signals and we get a feeling how long they are useful, e.g how quickly we lose our edge and fall back to randomness when we climb up the order sequence.
Currently, the martingale sequence is taken strictly, without evaluating the situation again (e.g with signals or filters) when the next order must be added to the sequence. Especially if we have higher pip steps and the whole trade takes a relatively long time to complete, their may be advantages if we introduce an explicit decision to try the next order. However, I don't know yet how it could look like, e.g. a confirmation signal.
Ok, I see that the next thing I need to build into my statistics function is to actually measure the edge at every level. On this basis it becomes easier to compare entry signals and we get a feeling how long they are useful, e.g how quickly we lose our edge and fall back to randomness when we climb up the order sequence. Currently, the martingale sequence is taken strictly, without evaluating the situation again (e.g with signals or filters) when the next order must be added to the sequence. Especially if we have higher pip steps and the whole trade takes a relatively long time to complete, their may be advantages if we introduce an explicit decision to try the next order. However, I don't know yet how it could look like, e.g. a confirmation signal.
I think coding this into an EA needs high level of programming skills.