Interesting, thanks for sharing. The way I do this is have offsets like Rob has in pysystem trade, then use those in combination with dates for which prices exist (I use this to eliminate weekends and holidays) to generate a list of roll dates. Then using that, and the actual prices, I generate adjusted prices. This works really well, unless in situations where data is wrong (wrong is worse than missing), like is the case with Platinum right now. Out of curiosity, how long does this take to run a backtest? I store adjusted prices, and at the beginning of the backtest I precompute and cache some stats, like all moving averages, all breakouts, risk etc. Then backtest just feeds in the current caapital and current price. For 12 instruments and 20 years this takes about 25 min, on a modern CPU. Granted, it's in Python and I haven't bothered to optimize so it only runs on a single core.
I'm also following the macro series of podcasts, really liking it so far. Is anybody else playing the "drink when Niels brings up Ray Dalio or The Fourth Turning" game?
The full backtest with all 37 instruments that I trade in paper account with all historical data that I have (1990 or later, depending on the instrument) takes hours, like many hours but less than a day don't remember exactly, maybe 3-4h?. It's not optimised for it, as in reality, a lot of heavy operations would be done only once a day and then cached for the rest of the day, but when I run it in the backtest mode on EOD prices it recomputes everything on every tick (in this mode I only substitute one module of the system that normally feeds RT bid-ask ticks from IB to instead read EOD prices from a database add and subtract average bib-ask spread for this contract making 2 prices Bid and Ask out of a single EOD price). The purpose of this is also to test my system in the exact conditions as if it was running in reality and see what comes out. I have good hardware (btw, noways one can buy a used double-xeon-CPU+256GBRam+Chinese-brand motherboard with 2 sockets online for like 1000$, which is a beast of a machine, so hardware is definitely cheaper than my time and sanity to endlessly optimise all of that ). The biggest reason for slowness is that I also run it in a single thread, but I can't really make it parallel, I don't know how to split it. Per instrument wouldn't work because there are some tnter-instrument-dependencies and I can't run different time intervals in parallel either because there's still some path-dependence in the system(e.g. when we calculate the current overall portfolio risk for the risk-overlay, or the current drawdown to reduce the current base-capital, etc., although some of these things can probably be ignored in a backtest..) But again, what I'm doing isn't really a backtest, it's just sort of technical quality-control\test of the system. A real research-style backtest is probably more appropriate to do in a vectorized form in some "matrix calculator" like matlab\python\R, ignoring certain not too-important things to make it possible and fast.. Btw, all the P&L stats I calculate on the individual contracts, because that's what I actually bought and sold in reality. And for things like volatility I use Rob's formulas (btw, the excel spreadsheets from here https://www.systematicmoney.org/systematic-trading-resources were quite useful for implementation as I remember )
Interesting.. "Prediction Company" had a sharp ratio of 3 over 15-20 year period: (the video is from 2014)., But looks like it was shut down in 2018. If, as it's written in some articles, it mostly did stat-arb, maybe that explains why my stocks pairs trading is not working at all
That's Doyne Farmer in the video who I met when he was visiting professor at Oxford in the same research centre which AHL funded. Fun guy! GAT
Thanks Rob. This ended up looking a bit complex in my implementation, so I'll put here which price I use for what if folks are interested. Below, by adjusted prices I mean prices modified to remove or smooth out differences between different contracts, also sometimes called stitching. By "carry prices" I refer to the actual traded price on a given day, for current (the one you're holding) and carry contracts. - computing risk (volatility) - adjusted prices for the price diff, carry prices for percentage (as Rob mentions in the quote above) - computing breakout rule - adjusted prices - computing MAC rule - adjusted prices - adjusting MAC rule for risk - risk computed on carry prices and current (last) price from carry prices (to get risk in price units) - computing carry rule - carry prices - price used for computing notional exposure - carry prices (this doesn't matter in the prod run as the latest price is the same in adjusted and carry series, but matters for backtest) - price used as fill price in backtest - adjusted price (on the fence for this one, but if I use actual price here, then there are bumps in PnL when rolling. Maybe that's the way it's supposed to be?) - price used for computing PnL in backtest - same as above Note to self: it would be awesome if the next system you make would work with non-dated instruments.
Did anyone look into trading coffee, sugar and cotton futures? the margins seem to be low (2-3k$), so should be good for small-capital systems, and these commodities should probably add good diversification compared to adding another stock index..?
Recently I did not look into these. But when I did so in the past I had the impression that the liquidity was rather low: the number of contracts being traded per day a lot lower than e.g. corn/wheat/soybean. Therefore I assumed that the bid/ask spread on these would be high. So I am currently not using these futures.