mirror of
https://github.com/wassname/catalyst.git
synced 2026-06-30 14:58:21 +08:00
DOC: Made the Welcome page a little more welcoming and moved high-level notes
out into a separate page.
This commit is contained in:
Tobias Brandt
+27
-44
@@ -3,56 +3,41 @@
|
||||
You can adapt this file completely to your liking, but it should at least
|
||||
contain the root `toctree` directive.
|
||||
|
||||
Contents:
|
||||
.. module:: zipline
|
||||
|
||||
*******************************************
|
||||
Zipline: The Open Source Backtesting Engine
|
||||
*******************************************
|
||||
|
||||
Python is quickly becoming the glue language which holds together data science
|
||||
and related fields like quantitative finance. Zipline is a new, BSD-licensed
|
||||
quantitative trading system which allows easy backtesting of investment
|
||||
algorithms on historical data. The system is fundamentally event-driven and a
|
||||
close approximation of how live-trading systems operate. Moreover, Zipline
|
||||
comes "batteries included" as many common statistics like
|
||||
moving average and linear regression can be readily accessed from within a
|
||||
user-written algorithm. Input of historical data and output of performance
|
||||
statistics is based on Pandas DataFrames to integrate nicely into the existing
|
||||
Python eco-system. Furthermore, statistic and machine learning libraries like
|
||||
matplotlib, scipy, statsmodels, and sklearn support development, analysis and
|
||||
visualization of state-of-the-art trading systems.
|
||||
|
||||
Zipline is currently used in production as the backtesting engine powering
|
||||
<Quantopian.com>_ free, community-centered platform that allows
|
||||
development and real-time backtesting of trading algorithms in the web browser.
|
||||
Zipline was released at PyData NYC'12.
|
||||
|
||||
Contents
|
||||
========
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 4
|
||||
|
||||
notes.rst
|
||||
overview.rst
|
||||
modules.rst
|
||||
messaging.rst
|
||||
|
||||
Zipline
|
||||
=======
|
||||
|
||||
Zipline runs backtests using asynchronous components and zeromq messaging for communication and coordination.
|
||||
|
||||
Simulator is the heart of Zipline, and the primary access point for creating, launching, and tracking simulations. You can find it in :py:class:`~zipline.core.Simulator`
|
||||
|
||||
Simulator Sub-Components
|
||||
========================
|
||||
|
||||
Each simulation contains numerous subcomponents, each operating asynchronously from all others, and communicating
|
||||
via zeromq.
|
||||
|
||||
DataSources
|
||||
--------------------
|
||||
|
||||
A DataSource represents a historical event record, which will be played back during simulation. A simulation may have one or more DataSources, which will be combined in DataFeed. Generally, datasources read records from a persistent store (db, csv file, remote service), format the messages for downstream simulation components, and send them to a PUSH socket. See the base class for all datasources :py:class:`~zipline.messaging.DataSource` and the module holding all datasources :py:mod:`zipline.sources`
|
||||
|
||||
DataFeed
|
||||
--------------------
|
||||
|
||||
All simulations start with a collection of :py:class:`~zipline.messaging.DataSource`, which need to be fed to an algorithm. Each :py:class:`~zipline.sources.DataSource`can contain events of differing content (trades, quotes, corporate event) and frequency (quarterly, intraday). To simplify the process of managing the data sources, :py:class:`~zipline.core.DataFeed` can receive events from multiple :py:class:`DataSources <zipline.sources.DataSource>` and combine them into a serial chronological stream.
|
||||
|
||||
Transforms
|
||||
--------------------
|
||||
|
||||
Often, an algorithm will require a running calculation on top of a :py:class:`~zipline.messaging.DataSource`, or on the consolidated feed. A simple example is a technical indicator or a moving average. Transforms can be described in :py:class:`~zipline.core.Simulator`'s configuration. Subclass :py:class:`~zipline.transforms.core.Transform` to add your own Transform. Transforms must hold their own state between events, and serialize their current values into messages.
|
||||
|
||||
|
||||
Data Alignment
|
||||
--------------------
|
||||
|
||||
Like Datasources, Transforms have differing frequencies and results. Simulator manages the results of parallel transforms and **aligns** transform results with the raw DataFeed. Client algorithms simply receive a map of data, which includes the current event and all the transformed values.
|
||||
|
||||
Time Compression
|
||||
--------------------
|
||||
|
||||
|
||||
Review the unit test coverage_.
|
||||
|
||||
|
||||
|
||||
Indices and tables
|
||||
==================
|
||||
@@ -60,5 +45,3 @@ Indices and tables
|
||||
* :ref:`genindex`
|
||||
* :ref:`modindex`
|
||||
* :ref:`search`
|
||||
|
||||
.. _coverage: cover/index.html
|
||||
|
||||
@@ -0,0 +1,47 @@
|
||||
*******************************************
|
||||
Overview
|
||||
*******************************************
|
||||
|
||||
Simulations
|
||||
===========
|
||||
|
||||
Zipline runs backtests using asynchronous components and zeromq messaging for communication and coordination.
|
||||
|
||||
Simulator is the heart of Zipline, and the primary access point for creating, launching, and tracking simulations. You can find it in :py:class:`~zipline.core.Simulator`
|
||||
|
||||
Simulator Sub-Components
|
||||
========================
|
||||
|
||||
Each simulation contains numerous subcomponents, each operating asynchronously from all others, and communicating
|
||||
via zeromq.
|
||||
|
||||
DataSources
|
||||
--------------------
|
||||
|
||||
A DataSource represents a historical event record, which will be played back during simulation. A simulation may have one or more DataSources, which will be combined in DataFeed. Generally, datasources read records from a persistent store (db, csv file, remote service), format the messages for downstream simulation components, and send them to a PUSH socket. See the base class for all datasources :py:class:`~zipline.messaging.DataSource` and the module holding all datasources :py:mod:`zipline.sources`
|
||||
|
||||
DataFeed
|
||||
--------------------
|
||||
|
||||
All simulations start with a collection of :py:class:`~zipline.messaging.DataSource`, which need to be fed to an algorithm. Each :py:class:`~zipline.sources.DataSource`can contain events of differing content (trades, quotes, corporate event) and frequency (quarterly, intraday). To simplify the process of managing the data sources, :py:class:`~zipline.core.DataFeed` can receive events from multiple :py:class:`DataSources <zipline.sources.DataSource>` and combine them into a serial chronological stream.
|
||||
|
||||
Transforms
|
||||
--------------------
|
||||
|
||||
Often, an algorithm will require a running calculation on top of a :py:class:`~zipline.messaging.DataSource`, or on the consolidated feed. A simple example is a technical indicator or a moving average. Transforms can be described in :py:class:`~zipline.core.Simulator`'s configuration. Subclass :py:class:`~zipline.transforms.core.Transform` to add your own Transform. Transforms must hold their own state between events, and serialize their current values into messages.
|
||||
|
||||
|
||||
Data Alignment
|
||||
--------------------
|
||||
|
||||
Like Datasources, Transforms have differing frequencies and results. Simulator manages the results of parallel transforms and **aligns** transform results with the raw DataFeed. Client algorithms simply receive a map of data, which includes the current event and all the transformed values.
|
||||
|
||||
Time Compression
|
||||
--------------------
|
||||
|
||||
|
||||
Review the unit test coverage_.
|
||||
|
||||
|
||||
|
||||
.. _coverage: cover/index.html
|
||||
Reference in New Issue
Block a user