TP2 related: Futures Prototyp (prio high)

[warren-oneill]

Purpose

Backtesting für Futures-Strategien mit einer Erweiterung des zipline-Frameworks.

Level of Ready

Umgebung

• Python 3.4
• git
• Github organization konto
• zipline master branch
• Entwicklungsstandards sind definiert und klar, z. B.
• Definition der private- und public-Komponenten
• Dokumentationsstandard, z. B. PEP257
• Programmier-Syntax(pep8,flake8 wie in zipline)
• Level Test-Coverage(nosetests wie in zipline)

Marktinfos

• Produkte müssen definiert sein EEX Produkten
• Trading-Kalender muss bekannt sein EEX Cal
• Fees müssen bekannt sein (€0.0125 per MW)
• Es muss eine Trading-benchmark festgelegt sein (constant benchmark)

Datenbank

• Beispiel PHELIX-Futures-Daten sind aus der Datenbank abrufbar

  Tasks

Markt

• Kalender & Zeitzone implementieren
  • muss mit echt daten vergleichen
  • erster Tag ist 01.01.2013
• New Benchmark (fixed annual rate)
  • zero Benchmark generiert bis 2016
  • muss Benchmark auto generieren/herunterladen
• fees (€ 0.0075 EEX Clearing per MWh für Futures)

Daten

• Futures Datenklasse
• load sql Daten

Produkte

• Produktklasse sind definiert
• Implementierung von Asset_MetaData
  • price, notice day, asset type
  • multiplier
  • double check notice and expiration day

Risk

• VaR
• Longest Drawdown

Ergebnisse und Output

• Im event-Betrieb werden jeder Trade und die aktuelle PnL, sowie Performance- und Risiko-Kennzahlen ausgegeben. Dazu gehören:
  • Kumulierte und täglich PnL
  • Kumulierte benchmark PnL
  • Volume
  • Returns (RoI)
  • VaR
  • Sharpe-Ratio
  • Sortino-Ratio
  • Information-Ratio
  • Max Drawdown
  • Longest Drawdown
• Analog zu den fortlaufenden Kennzahlen stehen im Ergebnis-Objekt finale Werte und Kennzahlen für jeden Monat, jedes Quartal und jedes Jahr.
  • VaR fehlt, alle andere Kennzahlen sind von Zipline über unterschiedlich Perioden gerechnet

    Level of Done

• Backtesting einer (einfachen) Strategie für weekly und monthly PHELIX futures
• Nutzung von unit tests
• Test-Coverage > 90%
• Dokumentation für alle Klassen und Methoden im Code
• Vergleich mit vektorisierter Lösung für Daten aus der Datenbank (für Zufallspreise nicht sinnvoll)
• Gebühren werden berücksichtigt (EEX Clearing fee, flat und prozentuale Banking fee, Broker fee)

[dhexus]

Regarding the "documentation standard" that should be in place: Simply type """ in PyCharm below a class or method and hit return. You'll a documentation template. Complete the documentation for each of your classes and methods.

[dhexus]

Moreover, please add author = 'warren' to sign your code.

[dhexus]

• why are asset_name, exchange, first_traded, root_symbol and start_date empty?
• it would be nice to have additional attributes begin_delivery and product_code (like F1B1 for weekly products)

[dhexus]

Looks like we could close this issue successfully soon. How much work is left?

[warren-oneill]

I just need to do

• why are asset_name, exchange, first_traded, root_symbol and start_date empty?
• it would be nice to have additional attributes begin_delivery and product_code (like F1B1 for weekly products)

[warren-oneill]

Looking into storing the metadata in a local SQL databanks so it doesn't have to be initialized every run. see https://github.com/quantopian/zipline/issues/714

[warren-oneill]

Moved from #45

• set 'auto_close_date' to last trading date (settlement price) before begin of delivery
• 'expiration_date' is the last date the future is valid, i.e. the last day of the delivery period (not begin_delivery)