Hi! To butt in here - my prod system (manual executed) is running off these git hash https://github.com/robcarver17/pysystemtrade/commit/e01cd6901971d988c7efdd0ee67612ae920cb65f which seems to be behave as I would expect. There was a heavy refactoring which occurred sometime after that commit which I have struggled to grok. IMO there was a lot of added complexity around caching which I found unnecessary for my simple needs, probably i'm too slow to get it. Will look again when time permits. I'm keen to try pysystemtrade on cash equities - has anyone tried?
What position size had you expected, or considered realistic? The maximum position size does not only depend on the account value, but also on (b) the portfolio weight assigned to corn and (b) your risk setting of the overall system.
probably I'm just way off here, but in which units this position size is (get_actual_position method)? I thought it's the number of contracts I should be long or short at each moment, so values around 60 seem quite large. just checked MXP and it shows maximum around 30. Maybe for 250k this is actually OK, just trying to do some sanity checking.. I'm actually more worried about carry estimated weight of 0.1, maybe I've missed some setup steps before running the backtest.. all I did was to run setup.py after getting the latest code
I don't know about the pysystemtrade software because I don't use it. But I do have some knowledge of the system it is based on. I have read Robert's (@globalarbtrader 's) book and built my own software to run it automatically. Now, let's do an approximate verification on the maximum number of corn contracts. Suppose you have an account size of 250 k USD and have set your annual account volatility target at 25%. That is 62.5 k USD. This translates to a daily volatility target of about 3.9 k USD. One contract corn currently has a daily value volatility of about 280 USD. Thus, if you would assign 100% of that account volatility target to corn, would that be the equivalent of 14 contracts. However, if the forecast is extremely bullish/bearish, might the program actually assign up to 1.5~2 times this number of contracts. Beware though that this analysis is based on the current value volatility of one corn contract. There have been periods in the past that the value volatility was higher, resulting in a lower maximum position size. And there have been periods that the value volatility was lower, resulting in a higher maximum position size. You can do a validation check on the other instruments in the same way.
Hi HobbyTrading, thanks for the reply, this example system is not 100% corn, it's the default chapter15 demo system with 6 instruments, so the initial positions do look unrealistic, but this is probably because in the beginning there's no data for some instruments, so the others are getting all the weight + maybe low vol in the begining.. (was discussed here: https://www.elitetrader.com/et/threads/fully-automated-futures-trading.289589/page-162) I Also built my own system based on the theory from the book, but it only does real-time calculations (i.e. on every new tick it can evaluate all the forecasts, volatilities, combines and caps all of this, etc.), but it doesn't do bootstrap optimisation and cost analysis (to calculate optimal forecast and instrument weights) and implementing it again is a big undertaking. + having another correct system is good for sanity checking (using the same parameters I can push historical data through my system and it would behave as it's trading it live and then compare the historical positions and performance to make sure everything is "as it should be"). Of course, there's also the option of using handcrafted weights for the instruments and forecasts... but, you know, bootstrap is fancier and more complicated, so it ought to be better but currently I'm hesitant to simply take pysystemtrade's optimal weights, because carry allocation 0.1 on all instruments doesn't make sense.. unless it somehow does and I'm just dumb
In case if someone is interested, enabling optimisation with costs as opposed to applying costs in the end (the default option), gives carry a more realistic allocation of around 0.4, so something strange seems to be happening in the code when costs are applied in the end.. working configuration (nothing else changed from the defaults): from systems.provided.futures_chapter15.estimatedsystem import futures_system system = futures_system(log_level="on") system.config.forecast_weight_estimate["cost_multiplier"]=3.0 system.config.forecast_weight_estimate["apply_cost_weight"]=False system.portfolio.get_notional_position("EUROSTX").tail(5) for instr in system.get_instrument_list(): system.combForecast.get_forecast_weights(instr).plot(title=instr) resulting weights: default configuration with apply_cost_weight=True : from systems.provided.futures_chapter15.estimatedsystem import futures_system system = futures_system(log_level="on") system.portfolio.get_notional_position("EUROSTX").tail(5) for instr in system.get_instrument_list(): system.combForecast.get_forecast_weights(instr).plot(title=instr) produces strange weights with carry down-weighted and fast rules up-weighted:
Interesting, thank you for sharing. Intuitively one would assume that the carry rule would indeed get approximately 50% assigned to it if it is only combined with several variations of the EWMAC rule.