Hi Rob, I'm working on implementing pysystemtrade and I'm stuck on the 'Pointsize' field in instrumentconfig.csv It responds to the get_value_of_block_price_move() function, which claims to produce "How much is a $1 move worth in value terms?" -- the documentation isn't much more enlightening either. In your book the closest thing seems to be the block value, which to refers to a 1% move... not a $1 move, which I don't really know how to interpret. Basically I'd like to know how you get to values such as 100000 for AUDUSD or 100 for Gold. I guess they relate to the block size, but how?
GAT, I’d like to compliment you. The current situation in global markets is volatile and a lot of stuff is happening on a daily basis. There are many charlatans in general and most info is rubbish / fake. You’ve done well for yourself, but more so, continue to provide very useful information to all of us. I make mention of P&L updates, having a dialogue with ‘the uninformed’ (‘yeah, TC don’t matter, never let a few bp get in between you and the trade of a lifetime, yadieyadieya’), cash management practices and mentioning that you’re getting back into beta. GAT, on behalf of the community, thanks!
To be fair there is a bit of natural confusion between the terminology in book, and in pysystemtrade. Let's talk about futures contracts specifically, as they are a bit harder than FX or equities (but not as bad as interest rate swaps and CDS that have variable block values!). If I check out the contract spec for Gold (here) it has some useful information: Contract size 100 troy ounces Min tick $0.10 Dollar value of one tick $10 I can also see that Gold is currently trading around $1600 per ounce. So if I buy a single Gold contract, that's like buying 100 troy ounces of gold at $1600 per ounce. That has a notional exposure (sorry more terminology!) of $160,000. If the price of Gold falls by 1%, then I will lose 1% of $160,000; i.e. $1600 (in this case this is equal to the price, but that is a coincidence). That is my definition of the block value: the amount you will win or lose owning one contract if the price moves by 1%. It's equal to the notional exposure of the contract multiplied by 1%. However what if the price of gold goes from $1600 to $1599? Then the value of what I own will go from $160,000 to $159,900. I will have lost $100. That is my definition of point size: the amount you will win or lose owning one contract if the price moves by $1 (or one GBP, whatever the contract is priced in). Notice that the point size is equal to the dollar value of one tick divided by the tick size (10/0.1 = 100). Notice also that the point size is equal to the number of 'thing's represented by the contract (in this case, troy ounces of Gold). These aren't coincidences; they will always be true. The notional exposure is equal to the price multiplied by the point size, and therefore the block value and point size are related as follows: block value = 1% * notional exposure = 1% * point size * price This transformation is implemented by the function systems.positionsizing.get_block_value Code: (underlying_price, value_of_price_move ) = self.get_instrument_sizing_data(instrument_code) block_value = 0.01 * underlying_price * value_of_price_move block_value.columns = ["bvalue"] For Gold: block value = 1% * 100 * price (Here is the source of the coincidence for Gold: the block value will always equal the price because the point size is $100 which exactly cancels the 1% factor. But for most contracts this won't be the case.) Hope that clears things up. The reason for the difference is that many people are more comfortable with percentage based risk rather than $ based risk. Bluntly, I was also trying to make my system sufficiently different from what AHL does to avoid being sued (mathematically they are the same, but appearances matter). However since the point size is a fixed unit, that is what has to appear in a specification file. GAT
Thanks FCT, that's very kind. Actually it's been very useful to be able to 'talk out loud', and quite cathartic. In the last crisis (2008) I was lucky enough to be working in a shop full of very smart people who I could bounce ideas off, and I feel lucky to have found a small group of people who (unlike most of the internet and ET generally) are smart and good listeners. Writing stuff down makes it easier for me to organise my thought processes. It also keeps me honest; if I started panicking and doing some discretionary punting I'd rightly be mocked and ridiculed. That peer pressure is a big help in sticking to a system in difficult times. And the dialogue is not just one way; I remember a few months ago when I was thinking of turning off my system for a while, and I was dissuaded by the posters on this board. That decision would have cost me a high five figure sum, maybe even low six figures. Incidentally, I give more regular updates on my risk exposure and non automated trading on twitter if anyone wants to see that: https://twitter.com/investingidiocy GAT
An update on this issue. It does indeed look like this is the problem, and it's caused by forecast thresholding (forecast mapping function). I tried to fix it, but the optimisation code is such a mess, I think it would be quicker to rewrite it. This isn't a priority right now, as I'm trying to get a production version of the code working so I'm focusing more on that. A work around is to follow the same procedure I do for fitting systems: - turn off forecast mapping - fit instrument weights without it - calculate the forecast mapping parameters - run the system with fixed instrument weights and forecast mapping turned on This actually makes more sense, since you don't know what the forecast mapping should be until you have the instrument weights. There are now functions that do the mapping calculations for you, see systems.diagoutput GAT
Actually I'm giving you guys slightly more credit than you're due: ... so I'd still be running the system now as the tax year has about 10 days left to run. But I still think you're great GAT
https://getyarn.io/yarn-clip/c4c6fb70-c04e-4e50-a195-08096d7cbc02 "Uh-uh-uh. I didn't hear you wash your hands." Ordell Robbie so is it really "Fully automated futures trading" if advice is taken from a human? on a more serious note, how do you feel about using equity curve data for position sizing, go/nogo, etc within automated systems? Thx
fantastic, thanks for laying it all out. It seems like I could've figured it out with a bit of digging, but this post just made it all clear.