Fully automated futures trading

Discussion in 'Journals' started by globalarbtrader, Feb 11, 2015.

  1. This is the downside of open source, especially with only one BDFL who can pull code.

    When you have a project on github you can name a 'successor'. Someone who can take it over if something happens. At some point I need to do it for pysystemtrade, although that is a much less popular and important project.

    I don't know if Ewald did this. The alternative is that someone respected takes a fork and maintains it. The danger is that you end up with multiple forks.

    Meanwhile as Hobby says the most appropriate place to discuss is here https://groups.io/g/twsapi/topics (the insync specific group has been deleted).

    Rob
     
    #3991     Mar 8, 2024
    newbunch likes this.
  2. What I read at the TWSAPI group is that there are already 150+ forks. So that danger is certainly present.
     
    #3992     Mar 8, 2024
    newbunch likes this.
  3. @newbunch For what it is worth: as of today (8 March 2024) am I still able to trade K200M (nicknamed KOSPI_mini). I'm not sure whether you are still following up on this topic. As I mentioned previously, my account is with IB US, but I'm not an American citizen.
     
    #3993     Mar 8, 2024
    newbunch likes this.
  4. Forks aren't bad -they mean the project is popular

    The problem is without a named successor, people won't know which fork to switch to that will be well maintained by someone credible. So it has to happen by consensus - a bit like a crypto fork. And the danger is you end up with two forks that are equally popular, or you back the wrong horse.

    Rob
     
    #3994     Mar 8, 2024
    newbunch and HobbyTrading like this.
  5. newbunch

    newbunch

    I have KOSPI disable. I'm not going to risk that they'll let me trade it but then prevent trading later. Besides, I can still trade KOSDAQ to get Korea exposure, though by my measure KOSDAQ and KOSPI are "only" 65% correlated.
     
    #3995     Mar 8, 2024
  6. Kernfusion

    Kernfusion

    I've been thinking, so when some rules are too expensive to trade for an instrument, we assign 0 weight to those rules for that instrument, and if all rules are too expensive, we remove the whole instrument.,
    But with DO, when an instrument is too expensive, we still keep it, just set maximum number of contracts to 0.
    And I think in such cases we should actually keep even the most expensive rules on the instrument, because their expensiveness only manifests when we trade it, and otherwise it's better to get the complete signal from that instrument through correlation matrix.

    Also, maybe it would be better to do the same thing with instruments which only allow to trade, say, quarter of the rules: i.e. instead of allowing trading relatively expensive instruments with only a few rules, it might be better to give them all the rules but set max contracts to 0 in DO..?
     
    Last edited: Mar 8, 2024
    #3996     Mar 8, 2024
    newbunch likes this.
  7. No

    https://qoppac.blogspot.com/2023/02/fast-but-not-furious-do-fast-trading.html

    Rob
     
    #3997     Mar 8, 2024
    Kernfusion likes this.
  8. Kernfusion

    Kernfusion

    The way I remember this post's conclusion is that basically throwing all instruments with all the rules into the DO and letting it automatically select\penalize expensive forecasts\instruments isn't optimal.

    But I didn't quite get the nuance about what should happen with the instruments which are too expensive to trade even the slowest rule, for sure we don't trade them, but, as I understood, we're still using them to form the forecast, but with which rule variations if all of them are too expensive?

    From the post:
    "I will consider two sub options here: forming forecasts for these instruments but not trading them (which is my current approach)"

    "Good news: all of this is a confirmation that what I'm currently doing* is probably pretty optimal!
    * running DO with expensive instruments, but not allowing them to trade, and preventing expensive instruments from using quicker trading rules."

    "(
    condition) Allocating conditionally to momentum speeds depending on the costs of an instrument and the turnover of the trading rule, ensuring I remain below the 'speed limit'. This is what I do now. Note that this will imply that some instruments are excluded completely."

    To me the first and the third statements seemed contradictory, but I think I get it now: there are 2 separate things:
    1. Removing the instrument based on it's SR cost per transaction, which should be less than 0.1SR
    2. Removing the rules which (considering turnover) cost more than 0.15SR

    And the best thing to do is to set DO_MaxContract=0(don't trade) for the first group of instruments, but allow them to be potentially used in forming the forecast but only with the rules which pass criteria 2., and if none of the rules pass it, then this instrument is not even participating in the forecast forming and effectively excluded from the system entirely.
     
    Last edited: Mar 8, 2024
    #3998     Mar 8, 2024
    newbunch likes this.
  9. Kernfusion

    Kernfusion

    Intuitively, though, it still seems strange that we're considering trading costs if we're not actually doing any trading with those very expensive instruments, and we can't even use them for forecasting.. I.e. why the expensiveness of an instrument also makes it bad at making forecasts.. But it is true empirically, so that's what it is I guess..
     
    Last edited: Mar 8, 2024
    #3999     Mar 8, 2024
  10. OK actually what I do with instruments that are too expensive for anything (Milk always comes up like this) is give them a 1/4 allocation in four very slow trading rules. So they do feed into the system but of course they will never show up with any trades or positions. There is only a very small number of them so this will make no difference at all, it just allows me to brag that I can potentially take positions in over 200 instruments (what I will be up to when my next implementation is done).

    Ro
     
    #4000     Mar 9, 2024
    Kernfusion likes this.