The purpose of this project is to simply set up shop, construct a program from an idea , and execute.
The EMA Crossover will enter the market at market price when the 20ema crosses the 200ema in the 15m time frame, going long when the 20ema higher than the 200ema on the 1D time frame. The stop loss will be the nearest swing, with the main take profit 3:1 from that.
To prevent over fitting of any kind, no variables will be set in the input, removing any chance of me over fitting ( for now ).
over a longer sample period ( 17 years ) the strategy is winning 40% of the time, and having large sideways ranges with a few jumps into profit. Looking at a smaller sample period, we see that even during a massive trend in the EUR/USD ( 2014-2016 ) the strategy can’t seem to profit consistently
No real surprise here, as we have gone down this road before. This was truly just an exercise to see how quickly I get myself back on the drawing board and automate a system .
By not creating input variables, I have less desire to optimize and more curious to see if we can see a saving grace to this simple idea.
So what could be improved? For starters, you will notice the equity line is bouncing around in the results graph. That means more than one trade is being executed because the criteria is being met ( the fast ma crossing the slow ma ) . Maybe in times of consolidation, to many losers are being put on at once. Lets refine the trade tracking in order to make it only open one at a time.
Right now, there is a flag variable “in_trade” that is set to false, and will only (should only, obviously not though ) open a trade when the in_trade flag is set to false. Once a trade is open, the order number is then placed into this variable, making it true, and theoretically not allowing more trades to occur.
After some investigation, I realized that my method for checking if the order was still open was not valid. I was using OrderClosePrice to see what the supposed “closed” price was, which is not what it does. OrderClosePrice and OrderOpenPrice returns the current price in relation to the order ( which makes no god damned sence since you can get the same number using Ask or Bid or even Close ).
So obviously, this is something that needs more addressing when using a strategy against multiple instruments.
For now, since we are just seeking alpha, and only want one order open, we will just simply use OrdersTotal.
So again, not much different, but now I notice that if a crossover occures , and a trade is open already, another trade will enter as soon as a stop is hit even if the move is nearly over.
Could using a stochastic or something similar help us to prevent this? As my experience has shown me before, we might be able to circumvent some losses, or strings of losses, but it isn’t what the strategy is not doing, but rather, what it was doing first.
So moving on to the next idea, which I wanted to warm up for, the purpose of this exercise, where what I hope to do is program the adviser to first look for SaR , and then go from there. I assume, with some sort of analysis occurring, there will be better chance for success.
This warm up excercise has reminded me that going forward, I need to be aware of:
- how there must be a system of control for orders set by the robot, within the same instrument with the assumption the robot will be running on more than one instrument within the same host.
- most importantly, I need to be careful of how I put the robot together, insuring that changes can be made dynamically and without retrofitting the strategy.
Lets see what happens