PacMan (my first hybrid) - page 9
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
Feel free to look through Phoenix 6 alpha. Here is an inbetween version, we should have a beta today. As long as you don't sell the code or rename it and republish, you can use it as you like.
What I would do in your situation is write a confirmation signal that checks to see how many failures you have had in a row, up to a certain limit. Resize the lots in the ConfirmationSignal response. It won't use pending orders anymore, but that also means it won't use random entry anymore. I don't think it will take much work to port the code over into this style, although there is a lot of extra stuff in there - most of which I enjoy. (mmm logging)
If you use static lot sizes, you can essentially look at the balance to see how well the loops worked. You should see doubling lots in the pending orders. (I did a few EA with doubling pending orders, it wasn't fun.) As for the calculations on the effectiveness of each signal, just look at ProfitFactor. If you want to measure each collection of signals independently, then you should probably run multiple backtests independently and compare profitfactor, although you could get away with weighted signals, etc. Required signal has weight 100, have 3 signals each with weight 5 and it takes 2 out of the 3 to agree on a trade = weight required 110.
I've seriously thought about the whole neural network with genetic algo, testing "what does this mean?" on indicators. I see this template as an intermediate step, but I really need MySQL based logging before it will become a reality. I'm already making dynamically scaling indicators and TP:SL levels, but interpreting data is the real hard part. I keep thinking each market type has a different wavelet function...
Anyway, this code should help. It is still alpha and some parts like hours and parabolic sar exits are untested.
Feel free to look through Phoenix 6 alpha. Here is an inbetween version, we should have a beta today. As long as you don't sell the code or rename it and republish, you can use it as you like. ...
Thanks for the new ideas and code to look at. This is quite some food for thought to chew on
Conclusion:
For the signal used it may be better to have a pyramiding approach:
As soon as the stop of the previous trade has been moved into garanteed profit, let this trade run and reevaluate the signal again to start another one, potentially pyramiding on top of the otherI have a different signaling process comming along nicely. Its up to 79% on an 8 pip equity target. I will have 80%+ soon.
I added an overbought/oversold filter to keep it from placing new orders after TP of old ones durring extreme levels. And also an added decision process to keep it only trading when the time is right. But still takes frequent trades.
Dave
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.
I did some experiments on my standard settings pips 5, tp 10, sl 10, but only for orders 1-2 (higher orders need tighter control because they must cover loss of lower orders) using trailing stop of 10 with the following findings:
- TP is never hit any more when adapted, caused by the 10 point stop distance limit by the broker, which doesn't allow me to have it closer when moved
- Average profit of orders 1-2 indeed goes up, even if they can close with only 5 pips profit
- Unfortunately, the total profit reduces because the trade rate decreases
=> this happens because the signal used often generates a new trade right after TP of the first, causing a grid-like behaviour, whereas the larger TP and trailing stop take more time to complete, reducing the trade rate
Conclusion:
For the signal used it may be better to have a pyramiding approach:
As soon as the stop of the previous trade has been moved into garanteed profit, let this trade run and reevaluate the signal again to start another one, potentially pyramiding on top of the other
OK. As promised.
Here is a back test of this year from Jan 1st to mar. 17th. 82% 8 pip equity target.
I wrote the code that "should" close trades based on S_Profit and L_Profit as the equity target. It compiles, ordersend function is good, but it don't work on back test. I'll be forward testing this version soon as I tweek entry signal little more. Hopefully the new target equity will work on forward running. I use the old target equity for back tests.
Soon as I see the new target equity works I'll update the first post with the new version.
I cann't code that trailing stop into this ea like you guys are talking about. So if you want to wait untill I get the %wins/signal/equity target done, then you guys can add the new trailing s/l feature. I'll test and re-optimise settings befor we give it to the public. I'd like to avoid having 5 versions, with 5 different mods. Just 2-3 versions with the best mods properly tweeked all in the final edition.
I am thinking in the way of mabe max trades =2, and a trailing s/l. Or 3 not sure till I can see it in action.
With high win% it might be able to have max trades 1 and a trailing s/l. And get rid of the subsequent orders.
just thinking out loud.
Dave
I can easily modify a system that checks open trades before enter to check open trade profit to enter again. Another way of handling this is to call my EnterNewTrade() (which has the signal checks) as part of the trailing stop function. Yay for modular code! Might as well turn it off/on with a setting.
Divergence/Convergence of price is a pretty solid filter for entering new trades. In Phoenix6 you can see the separation of Filter (trade allowed as boolean) from signal (buy vs sell) and I found this speeds up my back testing as well. (Why check 5 functions when the first one can tell you that the other 4 aren't needed?)
I have maxtrades as a configurable number. RecrossMax is the only function that isn't compatible with it, but I don't know if RecrossMax is important to this trading style.
Ok, I see that the next thing I need to build into my statistics function is to actually measure the edge at every level. ...
I have played with an experimental implementation of measuring our edge statistically:
Using JMA as signal, backtests claim a long term average edge of 11% (1999-2007), an edge of 9% for 2006 and only 4% so far in 2007. Conditions seem to be more difficult now ...
Our edge is computed as follows:
- Collect number of winners at every level and number of SLs hit
- For every level, compute the random walk probability of hitting TP before the next Pips level is reached: randomProb(TP before Pips) = Pips/(TP+Pips)
(at last level the SL must be used instead of Pips)
- For every level, compute the frequency of winners vs trades closing at higher levels, this is the measured probability
- Always count long and short trades separately
- Now take a weighted average of the differences of measured minus random probability (weighted by the sample size) at every level, this is our "average edge"
- Of course, different settings and different signals give a different edge
- Turn off fancy features like trailing stops and early profit taking, otherwise above computations don't apply, we want to test our signal, not the exit strategy
Hi Dave and All,
Do you still forward testing PacMan? How is the result? This week I started pacman with very large balance of 1 million
with the following setting:
MaxTrade = 12
Pip Step = 18
Without account protection
InitialStop = 100
TakeProfit = 28
Lot Size = 0.74
I hope 1 million will cover the worst case scenario that the ea will need to open maximum 12 trades, starting with 0.74 lot. With pip step of 18, it should be able to cover 216 pip. I know that 1 million is too exagerate
but I just want to see huge profit while it's running.
I'll report back on weekend.
Cheers,
I have played with an experimental implementation of measuring our edge statistically:
Using JMA as signal, backtests claim a long term average edge of 11% (1999-2007), an edge of 9% for 2006 and only 4% so far in 2007. Conditions seem to be more difficult now ...
Seems like you have been doing some great research! Mind if I ask how you were doing the statistical analysis? Trade comments + Excel, or a separate log file + grep? Ultimately I'd like to let the EA read/write data itself, but I haven't played with the string systems necessary for that yet. Most of what I'd want to do would require a database anyway :/
Seems like you have been doing some great research! Mind if I ask how you were doing the statistical analysis? Trade comments + Excel, or a separate log file + grep? Ultimately I'd like to let the EA read/write data itself, but I haven't played with the string systems necessary for that yet. Most of what I'd want to do would require a database anyway :/
The EA collects statistical data about winners/losers itself while closing trades and then prints its current state to the standard log.
Eventually, the trade history could be inspected directly and all statistics retrieved there instead of computing it incrementally. This could even be done by a separate EA (but it needs knowledge about pipsteps etc.).
However, we need to correctly identify orders belonging together to one trade, which can either be done by looking for identical closing time or by using a modified magic number identification.
Ongoing work, but interesting results, let's you measure the power of your signal vs random signals ...