From 3f969b7913b1b4bc2f6c88c692a47bbc1cdff75a Mon Sep 17 00:00:00 2001 From: Tobias Brandt Date: Wed, 14 Nov 2012 12:02:03 +0200 Subject: [PATCH] DOC: Made the Welcome page a little more welcoming and moved high-level notes out into a separate page. --- docs/index.rst | 71 ++++++++++++++++++----------------------------- docs/overview.rst | 47 +++++++++++++++++++++++++++++++ 2 files changed, 74 insertions(+), 44 deletions(-) create mode 100644 docs/overview.rst diff --git a/docs/index.rst b/docs/index.rst index 44172299..05ae6948 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -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 +_ 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 ` 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 diff --git a/docs/overview.rst b/docs/overview.rst new file mode 100644 index 00000000..5e48d686 --- /dev/null +++ b/docs/overview.rst @@ -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 ` 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