I completely understand you have other priorities, and I appreciate you taking the time to answer all the questions in this thread. No, costs are not eating up capital, it's the wrong kind of volatility.
https://qoppac.blogspot.com/2016/05/optimising-weights-with-costs.html I found the post here but the associated file is missing on github https://github.com/robcarver17/pysy...xamples/optimisation/optimisationwithcosts.py Can you please help with the file?
Did something happen with the MXP futures recently by any chance? I'm talking about this contract: https://misc.interactivebrokers.com/cstools/contract_info/v3.10/index.php?action=Conid Info&wlId=IB&conid=665383989&lang=en&ib_entity= Which actually has symbol "6M", although, in my system it's MXP (which might be the source of my problem) What triggered my attention is that I started receiving last close price for this contract (TickType=9) as 2.51, although, this price is way too high for this contract and should be around 0.05. In my database I have the last EOD price for this contract from May 12 and it looks normal (0.05081), but I haven't seen fresh EOD prices for 4 days now.. In my system I trust that TickType=9 LastClose more than the separately-collected EOD prices (maybe that's wrong..), so this MXP price caused all sorts of issues.. I can also see that the price of 2.51 seems to be coming from the Micro XRP (Symbol: MXPM25, Trading Class: MXP, Product Type Cryptocurrency????) Also, in TWS for 6M (if that's what I'm supposed to use now) I can't see historical EOD prices and the chart is also empty.. did they change the structure of the subscription packages somehow, or it's something temporary? Is there some kind of symbol migration going on at IB, for which I somehow missed notifications?
I have had no problems getting data for 6M/MXP and the prices are correct. However, some strange stuff has being going with it on IB's futures margin page: https://www.interactivebrokers.com/en/trading/margin-futures-fops.php It used to be MXP for the Underlying and 6M for the Trading Class. Then, earlier this week, the Underlying was MXPP, and my system, which looks at these margin requirements, couldn't match the instruments (in which case, it uses the previous value). But now both the Underlying and Trading Class are 6M and my system again can't match instruments. Not sure if or how this is related, but it could be.
While I have no trouble getting quotes and historical data using the old MXP symbol and 6M as the underlying, I do see that my positions report shows both the symbol and trading class as 6M. So far, because I use the contract ID to match positions to my instrument list, everything is fine, but I hope IB isn't in the process of messing everything up.
you mean you put '6M' as TradingClass when requesting RT\EOD data or there's another property 'Underlying' in the contract object ? (doesn't seem like it: https://interactivebrokers.github.io/tws-api/classIBApi_1_1Contract.html) I had TradingClass and LocalTradingClass as null for MXP in my system, CME as the exchange, Currency=USD. So I guess if I at least had "6M" as TradingClass I had no problems for now.. But yeah, looks like IB is changing something, as right now both the product and TradingClass are 6M in the TWS Description window, will see if it holds till Monday, but I'll probably change both Symbol and TradingClass to 6M. Btw, this started happening from May 15 for me..
So I ran my Commissions script, which uses whatIf orders to get the commission rates for trades. Both MXP/6M and 6M/6M "work," but both are giving me commissions of 0.87 whereas it had been 2.47. TWS also says commissions are 0.87.
I think I figured out why we are seeing some changes to the Peso futures. I typed MXP into TWS and the top item is the new Micro XRP futures (see at CME, where it indeed has the symbol MXP). So I'm guessing IB is replacing MXP with 6M to make way for the new MXP. I don't recall having had a symbol change like this before (I do recall when they changed Sugar from dollars to cents or the reverse), so I hope my system handles it well. (The issue may be how I store and retrieve historical data now that the symbol changes. I think my system will be fine, but I don't know for certain.)
I was working on some relative momentum rules (defined simply as the difference in forecast vs. asset class median); and noticed that some of the rules have gotten absolutely crushed in the second half of the sample (especially the very fast ones). Post 2010 Sharpe rrelewca4 -1.04 rrelewca8 -0.22 rrelewca16 0.21 rrelewca32 0.31 rrelewca64 0.27 rrelaccel_16 -0.13 rrelaccel_32 0.23 rrelaccel_64 0.25 rrelbreak20 -1.70 rrelbreak40 -0.81 rrelbreak80 -0.46 rrelbreak160 -0.16 rrelbreak320 -0.27 rrelnewca4 -1.82 rrelnewca8 -0.91 rrelnewca16 -0.42 rrelnewca32 -0.33 rrelnewca64 -0.32 Digging in a little deeper I noticed that fast asset class trend did really well over this period so seems like that combined with the weaker performance in fast absolute trend rules = mean reversion at the fast horizons. Another thing that stuck out was how badly relative momentum using breakouts did. Anyway was curious if there was any well motivated reason (beyond the sin of overfitting), of 1) Excluding faster relative momentum from the system (I think AFTS starts with a 10 day relative momentum rule - its at my office so I can't check on the weekend)? 2) Excluding certain momentum rules like breakout (and perhaps normalized trend)? I thought maybe the profile of mean reversion was different in a relative sense than it was in an absolute sense, which would justify excluding those faster relative momentum rules.