I know I just have to get around to it. Till now, I've cancelled backtests because I had to fix some UX thing. It's not yet painful enough for me to do, so in the meantime I'll let the problem fix itself in my head. That's just the "randomly generated slice" of time I'll backtest. Obviously needs some work
I thought someone might notice that the initial deposit was also made in the future, as far as the test goes
Buy vs build: fixing bugs In the process of persisting trades/backtests to the database, I ran into an odd situation after this change where my breakeven stop was submitting 2x the desired quantity. I didn't understand this was actually happening though. It just looked like a terrible bug. I had already created some small tests for a somewhat complex, but still straightforward piece of code that allowed me to observe changes to any Python object. I'd done this before for other projects but turned out it wasn't as important here after I had finished. Still, was a fun 3-4 hours of work, albeit wasted. It was only after reproducing the circumstance in a test case - I won't call it a unit test - that I could actually elaborate the issue. Behold, the test case: Code: self.model:Model self.instrument:Instrument cb = mock.MagicMock() tm:TradeManager = self.model.tradeManager() tm.eventAutoTradePlaced.connect(cb) order = tm.placeOrder(OrderAction.BUY,self.instrument) self.assertTrue(len(order.childOrders) == 2) trailing:Order profit:Order trailing,profit = order.childOrders self.assertGreater(order.limitPrice,trailing.limitPrice) self.assertGreater(profit.limitPrice,order.limitPrice) status = OrderStatus() status.orderId = order.orderId status.status = OrderStatusType.FILLED status.filled = order.totalQuantity status.remaining = 0 status.avgFillPrice = order.limitPrice order.status = status order.account = order.account self.assertEqual(self.account.positions[self.instrument].quantity,0) self.assertEqual(self.account.positions[self.instrument].price,0) self.model._broker.eventOrderUpdated(order) self.assertEqual(self.account.positions[self.instrument].quantity,order.totalQuantity) self.assertEqual(self.account.positions[self.instrument].price,order.limitPrice) initialQuantity = self.account.positions[self.instrument].quantity # simulate take profit fill status = OrderStatus() status.orderId = profit.orderId status.status = OrderStatusType.FILLED status.filled = profit.totalQuantity status.remaining = 0 status.avgFillPrice = profit.limitPrice profit.status = status profit.orderId = order.orderId + 1 profit.account = order.account self.model._broker.eventOrderUpdated(profit) self.assertEqual(self.account.positions[self.instrument].quantity,order.totalQuantity/2) self.assertTrue(cb.called) breakevenStop:Order breakevenStop, = cb.call_args_list[0][0] self.assertEqual(breakevenStop.action,OrderAction.SELL) self.assertEqual(breakevenStop.limitPrice,self.account.positions[self.instrument].price) self.assertEqual(breakevenStop.totalQuantity,profit.totalQuantity
Backtest results (~14% annualized) Finished another backtest ~90 days in length. This time the random slice went through the US presidential election. I mostly avoided losing too much money around there but only because I avoided trading USD except by accident (EURUSD). Annualized return of ~14% excluding transaction costs. This is risking max 1% of the account on each trade. Very annoying at the moment is not having basic things like an equity curve. My guess is that I should be able to create one by joining with the daily bars. Not really very many things left to do now except reporting and hooking up to IB. I'd like to hook up to IB so I can forward test with a paper account. I can work on the reporting in the meantime.
Buy vs build: debugging I had noticed that my huge wins were getting "stopped out" because of a bug in how I implemented trailing stops in my simulated broker. It caused enough problems in backtests today for me to fix it. You can see a case where the bug would have caused me to exit 2-3 bars after the move started (see the arrow) leaving a full 2/3 of the move on the sim table. These were random entries. Still ended up positive on that test lol. Pros: my test cases caught bugs in my bug fix Cons: Unfortunately, this bug took up a lot of frustrating backtest time until I gave in and fixed it, so not much progress today. Ah well.
Execution Reading globalarbtrader's book (don't want to @ him here), I've always thought the way he implemented the signals separately from the execution was pretty clever. In a nutshell the idea is that you have signals with a confidence level capped at -10/10 which you use to actually size positions and place trades. I'm debating whether I should do this now... I have all the pieces in place. Answering my own question: I think it's most important to get the paper trading set up, and then if I need to protect me against myself, I can implement such a system.
In his system you don't go "full in" and "full out", but you gradually increase/decrease your position size. It is not a binary system. The amount with which you increase/decrease your position size depends on your account value, your risk appetite and the volatility of the instrument.
I'll definitely have to re-read that part of it. It's been a while since I read it. What are your thoughts on the approach in general? It seems decent.
I am running a futures trading system largely based on the book you referred to. However, I did not use the Python code he provided, but wrote the entire code in Java. Although the core strategy is still in place, many of the practical aspects are rather different from how he implemented it. I think that there are "two schools of thought". One school says that if you are convinced of a certain trade you should go full into it, or with a fixed portion of your account value (you often see "1% of account value", or statements like that). The second school subscribes to the idea that your position size should be adjusted to (a) the riskiness of the trade and (b) how convinced you feel about this trade. This results in fading into, and fading out of, positions. I like the second school of thought because it also enables a way to compare trade possibilities between various instruments. Which instrument has a higher conviction? Which instrument carries a higher risk?
Similarly, I don't think I would re-use his code, not that it's bad or anything just that I would understand it better if I wrote it myself. I think either schools of thought are still too complicated for me at the moment. I don't think I'm smart enough to know how convinced I am of a trade, rather I would want to make sure my exposure to a certain currency does not exceed X% of my account balance. That's probably all I would do to start as at the moment, I do it by heuristic. If memory serves, your system is trend following as well?