Comments (4)
Er.... I think the code already includes relative volume (price vs forward which I think is more relevant as there could be a case when the most liquid contract is sometehing else). But it doesn't include a minium number of contracts. So you are proposing adding the latter as a threshold?
from pysystemtrade.
I did mean the relative volume between the forward contract and the most liquid contract. (I already implemented the check on the minimum number of contracts in a previous PR.) I can now see that you might not need it though for a decent automated roll procedure.
A tentative roll procedure that doesn't need the relative volume between the most liquid and forward contract:
- if relative volume between current and forward contract > 1, then roll (and no need to check absolute volume);
- if relative volume between current and forward contract > X (say, 0.1), then roll if absolute volume >Y (say 100).
Only do this for contracts that are within Z (say, 10) days from expiry.
My previous thinking was:
Sometimes you are in a situation where the relative volume between the forward contract and the current contract (as implemented now) is relevant: if the forward contract is more liquid than the current contract, you almost surely want to roll; also, if the forward contract is decently liquid compared to the current contract (say 10% of the volume) and has decent absolute liquidity (say, at least 100 contracts a day of volume), then you probably want to roll.
Other times, however, the relative liquidity between the forward contract and the most liquid contract seems more relevant. I am thinking mostly of instruments where the absolute liquidity is very low (below 100 contracts a day, for example) and you want to roll in such a way that you stay very close to the most liquid contract (ideally, in the most liquid contract). You might also be able to handle those cases by just rolling those if the relative volume between the current and forward contract reaches 1.
from pysystemtrade.
Note to self, if forward contract also not liquid but close to rolling might auto-consider NO-OPEN status
from pysystemtrade.
I'm not sure throwing in the most liquid contract is useful here. Instead, I propose the following to improve the automation of rolling:
- Add a function that suggests the best roll status. For roll options 0 and 1 this will be advisory, for roll options 2 and 3 it will be used to decide automatically what to do
- Implement a set of simple rules which can be modified on the fly (as for interactive_manual_update_prices, you get the option to do this if you enter 2 or 3 - this replaces the existing dialog of minimum relative volume, manually prompt for state if I have position)
- The variables for the simple rules can also be changed in the config (and hence private_config)
- The rules build on what you have said, and also what I discussed in #931
- Since we don't know if the user is running dynamic optimisation (DO), we have to include options that allow appropriate behaviour.
Rules here, with parameters in BOLD ITALICS:
- Is the forward contract liquid? (see below)
- Forward not liquid. Are we close to the roll point? (is distance to expiry<NEARING_EXPIRY_DAYS)
- No, miles away from needing to roll. Trade as normal: NO_ROLL
- Yes, going to roll quite soon. Roll status should be NO_OPEN. We don't want to trade the forward - it's not liquid yet. And we don't want to open a position or increase it in the current priced contract, since we will only have to close it again soon. But we do want to allow ourselves to close any position we have in the current priced contract.
- Forward is liquid. This is the classic list of roll possibilities:-
- We have no position in the priced contract: ROLL ADJUSTED
- Do we have plenty of time? (is distance to expiry>NEARING_EXPIRY_DAYS)?
- Yes, We have plenty of time PASSIVE ROLL ( Any trades generated by DO will close priced, open up forward contract positions)
- No, we don't. The following options would appear as discretionary options since it's a matter of judgement, and taste, and requires information we don't have (liquidity in the spread market). They could also be pre-selected with a parameter, DEFAULT_ROLL_STATUS_IF_UNDECIDED
- If spread market liquid, can do FORCE ROLL (Any trades generated by DO will be ignored as contract orders won't be generated for them due to the roll status.)
- If spread market iliquid, can do FORCE OUTRIGHT (Any trades generated by DO will be ignored as contract orders won't be generated for them due to the roll status.)
- We are in a hurry, and eithier the spread market isn't liquid, or we want to leave DO with the option of not opening the new position. So we go for CLOSE PRICED CONTRACT.
- Forward not liquid. Are we close to the roll point? (is distance to expiry<NEARING_EXPIRY_DAYS)
The test for forward being liquid would be as you say:
- if relative volume between current and forward contract > AUTO_ROLL_IF_RELATIVE_VOLUME_HIGHER_THAN, then roll (and no need to check absolute volume);
- if relative volume between current and forward contract > MIN_RELATIVE_VOLUME, then roll if absolute volume >MIN_ABSOLUTE_VOLUME
(The auto roll options already only consider contracts within N days, so that doesn't need to be included)
from pysystemtrade.
Related Issues (20)
- ignore/bad market not working in remove markets report
- Bug in spawn_children_from_instrument_orders HOT 4
- Hold turnover calculation HOT 1
- stack handler crash - creating contract orders from instrument orders HOT 1
- weird expiry date format for GASOIL, EURIBOR-ICE, ROBUSTA HOT 10
- Close order did not work as expected HOT 4
- Error splitting passive roll order HOT 1
- Repeatedly "Sending order ((Order ID:230) Type best for _ROLL_PSEUDO_STRATEGY/......" HOT 6
- modify auto roll code so rolls adjusted if price contract has expired HOT 2
- add correlations to duplicate markets
- remove markets report points out double counting of bad/stale/ignored/trading restriction markets
- Another trade_qty, integer issue HOT 1
- Sending Reports by Email HOT 3
- Stack Handler Crash
- Stack Handler Crash Not Resolved HOT 8
- missing get_demeanded_factor_value HOT 1
- private_config_trading_hours.yaml gets deleted by run_cleaners HOT 3
- Crash on Futures when the last Contract is expired HOT 2
- (?) csvFuturesSimData' object has no attribute 'get_instrument_object_with_meta_data HOT 1
- using current python (3.11) and current everything else is possible HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pysystemtrade.