Trading the anti-grid with the snowball EA
I just discovered this via 7bit's home page because of Python and R integration. My gosh. Nice! It doesn't seem to want to work with MBTrading in BIDIR mode but a single direction works.
In order to "remote control" it, I think I'll be updating checkLines() to check for "stop long" and "stop short" so I can control how far it attempts to catch the correct direction.
I am also considering adding max levels and a way to skip adding an order if criteria aren't met. No need to keep trying to go long when it's in a clear down trend. I'd also...
I will be waiting for your modifications.
I am definitely not on the same level as 7bit, not even close. Additional testers are helpful of course! The additional checks for lines should be as simple as adding this to checkLines().
Then you can manually put up lines or an indicator could use 7bit's very helpful common_functions.mqh to add and move lines using horizLine().
The problem with the others is that in my initial review of the code, things like break even and autoTP would not function correctly with my proposed changes because there would be gaps in the levels.
For example getTheoreticProfit() uses a multiplier and distance for its calculation. However, getBreakEven, while not elegant as 7bit calls it, is flexible enough to work with different ways of calculating breakeven since it basically does it with brute force number crunching.
You can imagine that if you have the slope of a moving average as one of the criteria for running a direction, i.e. only run long with a + slope. On a retrace it won't continue to try to add levels. If the retrace happens to happen such that the lagging slope turned around so there were no gaps in new levels, no problem. But if the price retraced then suddenly jumped a couple levels before the lagging slope indicator caught up with it, then the problem comes in.
Max levels would suffer the same issue with those calculations.
That break even line is a wonderful representation of how the grid quickly builds back profit though. I would want to figure out a way to get that correct but I am not an EA developer. Fortunately 7bit's code is so clean it actually makes sense.
So it's good to be able to see that you don't need to get back to your entry, just enough levels to erase the losses and that grows so nicely as it pyramids up. It's like having the benefits of a martingale without the same associated risks.
Additional testers are helpful of course! The additional checks for lines should be as simple as adding this to checkLines().Inserted Code
if (crossedLine("stop short")){
stop();
}
if (crossedLine("stop long")){
stop();
} Then you can manually put up lines or an indicator could use 7bit's very helpful common_functions.mqh to add and move lines using horizLine().
The problem with the others is that in my initial review of the code, things like break even and autoTP would not function correctly with my proposed changes because there would be gaps in the levels.
For example getTheoreticProfit() uses a multiplier and distance for its calculation. However, getBreakEven, while not elegant as 7bit calls it, is flexible enough to work with different ways of calculating breakeven since it basically does it with brute force number crunching.
You can imagine that if you have the slope of a moving average as one of the criteria for running a direction, i.e. only run long with a + slope. On a retrace it won't continue to try to add levels. If the retrace happens to happen such that the lagging slope turned around so there were no gaps in new levels, no problem. But if the price retraced then suddenly jumped a couple levels before the lagging slope indicator caught up with it, then the problem comes in.
Max levels would suffer the same issue with those calculations.
That break even line is a wonderful representation of how the grid quickly builds back profit though. I would want to figure out a way to get that correct but I am not an EA developer. Fortunately 7bit's code is so clean it actually makes sense.
So it's good to be able to see that you don't need to get back to your entry, just enough levels to erase the losses and that grows so nicely as it pyramids up. It's like having the benefits of a martingale without the same associated risks.
- #92
- Edited 7:08pm Mar 25, 2011 10:03am | Edited 7:08pm
Heh I don't think I'll be able to git level skipping in there and still be able to keep a lot of the functionality, especially the info displays. I actually have to check if I can actually get it to skip levels and still work as expected. Otherwise I'll have to attempt to port it over to TradeLink which is where I normally do dev but it would be a drastically stripped down version.
...edit...
Yeah it is tightly tied to having consistent levels in place. I started making a stripped down version but trade() and resume() both also use level in a way that is tied to the number of current orders, etc. It needs to be perhaps an array of levels that is stored or... hmm... in trade()
perhaps that could get the difference between the highest and lowest open orders and divide by the distance. That could work perhaps. Just have to make a getHighestPositionPrice and getLowestPositionPrice in the fabulous common_functions.mqh so it would be something like
which still needs to be worked out.
resume() though is a different beast. Instead of using level to figure out how many orders to place perhaps it could do
to determine the number of orders to open instead of using level and just use level to determine if it should buy or sell.
Thinking out loud here as I would like to test this as soon as possible. When I have some time to work those changes in I'll post up the snowball stripped down version. It doesn't have breakeven, take profit, and many other things. Just the basic grid order placement.
...edit...
resume() won't work since it needs the previous stop losses. So basically when it successfully makes an order it has to store that, somewhere, and when an order closes for whatever reason, remove that order from the stored list.
So REALLY what is needed is a way to reliably serialize open orders and keep that in sync when orders close out. resume() would just pop that open and repopulate the orders then. Hmm... is there any way to be notified when an order closes?!
...edit...
I see there are no order events until MQ5. Oh well. So basically pause would have to get all the open orders and serialize them, and resume would read that in. And any time an order is successfully placed it should be serialized into the queue as well. Oh boy...
...edit...
Yeah it is tightly tied to having consistent levels in place. I started making a stripped down version but trade() and resume() both also use level in a way that is tied to the number of current orders, etc. It needs to be perhaps an array of levels that is stored or... hmm... in trade()
Inserted Code
level = getNumOpenOrders(OP_BUY, magic) - getNumOpenOrders(OP_SELL, magic);
perhaps that could get the difference between the highest and lowest open orders and divide by the distance. That could work perhaps. Just have to make a getHighestPositionPrice and getLowestPositionPrice in the fabulous common_functions.mqh so it would be something like
Inserted Code
level = (getHighestPositionPrice(OP_BUY, magic) - getLowestPositionPrice(OP_SELL, magic)) / stop_distance * points_per_pip;
which still needs to be worked out.
resume() though is a different beast. Instead of using level to figure out how many orders to place perhaps it could do
Inserted Code
getNumOpenOrders(OP_SELLSTOP, magic)
Thinking out loud here as I would like to test this as soon as possible.
When I have some time to work those changes in I'll post up the snowball stripped down version. It doesn't have breakeven, take profit, and many other things. Just the basic grid order placement....edit...
resume() won't work since it needs the previous stop losses. So basically when it successfully makes an order it has to store that, somewhere, and when an order closes for whatever reason, remove that order from the stored list.
So REALLY what is needed is a way to reliably serialize open orders and keep that in sync when orders close out. resume() would just pop that open and repopulate the orders then. Hmm... is there any way to be notified when an order closes?!
...edit...
I see there are no order events until MQ5. Oh well. So basically pause would have to get all the open orders and serialize them, and resume would read that in. And any time an order is successfully placed it should be serialized into the queue as well. Oh boy...
Got a better idea ... ...
Will be moving to http://www.forexfactory.com/showthre...77#post4505477
7Bit, do you think you can contribute to the thread i just quoted above?
Many thanks.
Will be moving to http://www.forexfactory.com/showthre...77#post4505477
7Bit, do you think you can contribute to the thread i just quoted above?
Many thanks.
ç¦ å Victor V