Obviously I am less patient than you. In my case the algorithm is simpler: If the bid/ask spread is more than one tick I place a limit order halfway between bid and ask. If that order is not filled within one minute then I cross the spread and get the order filled. If the bid/ask spread is only one tick I can't be bothered and cross the spread, so that my order gets filled immediately.
I've got a question about instruments with fewer price data. For example, running pysystemtrade with default price config, I have no adjusted prices for VNKI since 11/15. The priced contract Feb 2023 has no data since 11/15 either, so presumably the default setting of 'ignore prices with zero intra-day volume' is doing that. If I look at barchart, it does look like a few contracts were traded and prices changed after 11/15. I'm not sure why there is a discrepancy. At what point would you drop an instrument with less price data? Or give it less instrument weight? Or change the price/carry contracts 1 month nearer since they have more volume? This is where my relative ignorance of futures comes in. Thanks!
Sorry my fault. This is one of Rob's acronyms that doesn't easily translate. It's the Nikkei 225 Volatility index futures.
Vaguely confident in the data shown here (but sceptical about my use of "value_of_block_price_move"). The "minimum capital GBP" is based on a system with 15% volatility target. Who can correctly name instruments A, B, C? A better chart would also colour code the bubbles based on risk adjusted trading costs (very red = very expensive).
Hi Rob, Sorry if it's been already asked and I missed it. Since you're trading with the DO algorithm which tends to limit your trading costs, why do you still remove the expensive trading rules? It appears redundant. Are they that detrimental to the portfolio's performance? Thank you!
You should still be getting daily prices, so it might be worth running pysystemtrade/ . interactive_manual_check_historical_prices for VNKI. I just did that and I have a price for Monday now so there was obviously a trade. I generally carry on collecting prices (such as they are) for everything in case at some point they start becoming active again. Instrument weights, tricky one. If you are using dynamic optimisation then the worst case scenario is the relevant future is adding 'noise' to the overall pot since you should not be trading it. With the size of my overall portfolio that doesn't personally bother me for a few instruments. Of course if you are using the standard methodology, you would have an instrument weight of zero You can try rolling earlier to see if that helps, if it does then a permanent change to the config might be in order. Ah if only someone would write a book about futures... Rob
Well as nobody else has guessed... A is probably full size ethereum and C I think is probably mini bitcoin. B is almost certainly some kind of short end bond (I'd say interest rate future, but the exposure is wrong). Rob
That's an excellent question. In fact I started writing a blog post about it. It's actually a very hard question to answer, as it turns out (hence the blogpost remaining defiantly unfinished) I guess my answer for now, pending further thought, is that I'd rather do something that's probably redundant than risk doing something that has a chance of increasing my trading costs for no net benefit. Rob PS A related question for the 'basic' system is "Since buffering reduces turnover, you can keep all fast trading rules in, right?"