Python Forex Zurück Testen

Python Algorithmic Trading Library PyAlgoTrade ist eine Python Algorithmic Trading Library mit Fokus auf Backtesting und Unterstützung für Papierhandel und Live-Trading. Lets sagen, Sie haben eine Idee für eine Handelsstrategie und youd mögen es mit historischen Daten auswerten und sehen, wie es sich verhält. PyAlgoTrade ermöglicht es Ihnen, dies mit minimalem Aufwand zu tun. Hauptmerkmale Vollständig dokumentiert. Ereignisgesteuert . Unterstützt Markt-, Limit-, Stop - und StopLimit-Aufträge. Unterstützt Yahoo Finance, Google Finance und NinjaTrader CSV Dateien. Unterstützt jede Art von Zeitreihendaten im CSV-Format, zB Quandl. Bitcoin Handelsunterstützung durch Bitstamp. Technische Indikatoren und Filter wie SMA, WMA, EMA, RSI, Bollinger Bands, Hurst Exponent und andere. Performance-Metriken wie Sharpe-Ratio und Drawdown-Analyse. Umgang mit Twitter-Events in Echtzeit. Event-Profiler TA-Lib-Integration. Sehr einfach zu skalieren horizontal, das heißt, mit einem oder mehreren Computern zu backtest eine Strategie. PyAlgoTrade ist kostenlos, Open Source, und es ist unter der Apache Lizenz lizenziert, Version 2.0.Event-Driven Backtesting mit Python - Teil I Weve verbrachte die letzten paar Monate auf QuantStart Backtesting verschiedene Handelsstrategien mit Python und Pandas. Die vektorisierte Natur von Pandas sorgt dafür, dass bestimmte Operationen auf großen Datensätzen extrem schnell sind. Doch die Formen des vektorisierten Backtests, die wir bisher studiert haben, leiden unter einigen Nachteilen in der Art und Weise, wie die Handelsausführung simuliert wird. In dieser Reihe von Artikeln werden wir einen realistischeren Ansatz für die historische Strategie-Simulation diskutieren, indem wir eine ereignisgesteuerte Backtesting-Umgebung mit Python konstruieren. Event-Driven Software Bevor wir uns mit der Entwicklung eines solchen Backtests vertraut machen, müssen wir das Konzept der ereignisgesteuerten Systeme verstehen. Videospiele bieten einen natürlichen Anwendungsfall für ereignisgesteuerte Software und bieten ein einfaches Beispiel zu erkunden. Ein Videospiel hat mehrere Komponenten, die miteinander in einer Echtzeit-Einstellung bei hohen Frameraten interagieren. Dies wird durch Ausführen des gesamten Satzes von Berechnungen innerhalb einer Endlosschleife, die als Ereignis-Schleife oder Spiel-Schleife bekannt ist, behandelt. Bei jedem Tick der Game-Loop wird eine Funktion aufgerufen, um das aktuelle Event zu erhalten. Die durch einige entsprechende vorherige Maßnahmen innerhalb des Spiels erzeugt worden sind. Abhängig von der Art des Ereignisses, die einen Key-Press oder einen Mausklick beinhalten könnte, wird eine nachfolgende Aktion durchgeführt, die entweder die Schleife beendet oder einige zusätzliche Ereignisse generiert. Der Prozess wird dann fortgesetzt. Hier ist ein Beispiel Pseudocode: Der Code überprüft ständig nach neuen Ereignissen und führt dann Aktionen aus, die auf diesen Ereignissen basieren. Insbesondere ermöglicht es die Illusion von Echtzeit-Antwort Handling, weil der Code wird ständig geschleift und Ereignisse überprüft. Wie sich herausstellen wird, ist genau das, was wir brauchen, um Hochfrequenz-Handelssimulation durchzuführen. Warum ein Event-Driven Backtester Event-driven Systeme bieten viele Vorteile gegenüber einem vektorisierten Ansatz: Code Reuse - Ein Event-driven Backtester, von Design, kann sowohl für historische Backtesting und Live-Trading mit minimaler Ausschaltung von Komponenten verwendet werden. Dies gilt nicht für vektorisierte Backtesters, bei denen alle Daten zur Verfügung stehen müssen, um statistische Analysen durchzuführen. Lookahead Bias - Mit einem ereignisgesteuerten Backtester gibt es keine Lookahead-Bias, da der Marktdatenbeleg als ein Event behandelt wird, auf das man achten muss. So ist es möglich, einen ereignisgesteuerten Backtester mit Marktdaten zu füllen und zu replizieren, wie sich ein Auftragsmanagement und Portfolio-System verhalten würde. Realismus - Event-driven Backtesters ermöglichen eine signifikante Anpassung an die Ausführung von Aufträgen und Transaktionskosten. Es ist einfach, grundlegende Markt - und Limitaufträge zu behandeln, sowie Markt-on-Open (MOO) und Market-on-Close (MOC), da ein benutzerdefinierter Austausch-Handler aufgebaut werden kann. Obwohl ereignisgesteuerte Systeme mit vielen Vorteilen kommen, leiden sie unter zwei großen Nachteilen gegenüber einfacheren vektorisierten Systemen. Erstens sind sie wesentlich komplexer zu implementieren und zu testen. Es gibt mehr bewegte Teile, die zu einer größeren Chance führen, Bugs einzuführen. Um diese korrekte Software-Testmethodik zu mildern, wie z. B. Test-getriebene Entwicklung eingesetzt werden kann. Zweitens sind sie im Vergleich zu einem vektorisierten System langsamer. Optimale vektorisierte Operationen können bei der Durchführung mathematischer Berechnungen nicht genutzt werden. Wir werden über Möglichkeiten diskutieren, diese Einschränkungen in späteren Artikeln zu überwinden. Event-Driven Backtester Überblick Um einen ereignisgesteuerten Ansatz für ein Backtesting-System anzuwenden, müssen wir unsere Komponenten (oder Objekte) definieren, die bestimmte Aufgaben behandeln werden: Event - Das Event ist die grundlegende Klasseneinheit des ereignisgesteuerten Systems. Es enthält einen Typ (wie MARKET, SIGNAL, ORDER oder FILL), der bestimmt, wie er innerhalb der Event-Loop behandelt wird. Event Queue - Die Event Queue ist ein In-Memory-Python-Queue-Objekt, das alle Event-Sub-Class-Objekte speichert, die vom Rest der Software generiert werden. DataHandler - Der DataHandler ist eine abstrakte Basisklasse (ABC), die eine Schnittstelle zur Handhabung von historischen oder Live-Marktdaten präsentiert. Dies bietet eine erhebliche Flexibilität, da die Strategy - und Portfolio-Module so zwischen beiden Ansätzen wiederverwendet werden können. Der DataHandler erzeugt bei jedem Herzschlag des Systems ein neues MarketEvent (siehe unten). Strategie - Die Strategie ist auch ein ABC, das eine Schnittstelle für die Erfassung von Marktdaten und die Erzeugung entsprechender SignalEvents darstellt, die letztlich vom Portfolio-Objekt genutzt werden. Ein SignalEvent enthält ein Tickersymbol, eine Richtung (LONG oder SHORT) und einen Zeitstempel. Portfolio - Dies ist ein ABC, das das Auftragsmanagement mit aktuellen und nachfolgenden Positionen für eine Strategie verknüpft. Es führt auch das Risikomanagement über das Portfolio hinweg, einschließlich der Sektorexposition und Positionsbestimmung. In einer anspruchsvolleren Implementierung könnte dies in eine RiskManagement-Klasse delegiert werden. Das Portfolio nimmt SignalEvents aus der Warteschlange und generiert OrderEvents, die der Warteschlange hinzugefügt werden. ExecutionHandler - Der ExecutionHandler simuliert eine Verbindung zu einem Brokerage. Die Aufgabe des Handlers ist es, OrderEvents aus der Warteschlange zu nehmen und sie entweder über einen simulierten Ansatz oder eine tatsächliche Verbindung zu einer Lebervermittlung auszuführen. Sobald Aufträge ausgeführt werden, schafft der Handler FillEvents, die beschreiben, was tatsächlich getätigt wurde, einschließlich Gebühren, Provision und Schlupf (wenn modelliert). Die Loop - Alle diese Komponenten sind in einer Event-Loop verpackt, die alle Event-Typen korrekt behandelt und sie an die entsprechende Komponente weiterleitet. Das ist ein Grundmodell eines Handelsmotors. Es gibt erhebliche Expansionsmöglichkeiten, vor allem in Bezug auf die Nutzung des Portfolios. Darüber hinaus können unterschiedliche Transaktionskostenmodelle auch in ihre eigene Klassenhierarchie abstrahiert werden. In diesem Stadium stellt es unnötige Komplexität innerhalb dieser Reihe von Artikeln, so dass wir derzeit nicht weiter diskutieren werden. In späteren Tutorials werden wir wahrscheinlich das System erweitern, um zusätzlichen Realismus einzuschließen. Hier ist ein Snippet von Python-Code, der zeigt, wie der Backtester in der Praxis funktioniert. Es gibt zwei Schleifen, die im Code auftreten. Die äußere Schleife wird verwendet, um dem Backtester einen Herzschlag zu geben. Für den Live-Handel ist dies die Häufigkeit, mit der neue Marktdaten abgefragt werden. Für Backtesting-Strategien ist dies nicht unbedingt notwendig, da der Backtester die im Drip-Feed-Formular bereitgestellten Marktdaten verwendet (siehe die Zeile bars. updatebars (). Die innere Schleife behandelt die Ereignisse aus dem Ereignis-Warteschlangenobjekt. Spezielle Ereignisse werden an die jeweilige Komponente delegiert und anschließend werden neue Ereignisse der Warteschlange hinzugefügt. Wenn die Ereignis-Warteschlange leer ist, geht die Heartbeat-Schleife weiter: Dies ist die grundlegende Übersicht, wie ein ereignisgesteuerter Backtester entworfen wurde. Im nächsten Artikel werden wir die Eventklassenhierarchie besprechen. Nur mit dem quantitativen Handel begonnen