zipline-reloaded Documentation

A TradingCalendar represents the timing information of a single market exchange. It consists of two main components:

1. Sessions: A contiguous set of minutes with a label (conventionally midnight UTC).
2. Opens/Closes: The specific times the market starts and ends trading.

Importance for Backtesting: Your TradingCalendar must match the dates available in your data bundle. If you attempt to place a trade on a day when the exchange is closed (e.g., a Saturday for the NYSE), the backtest will fail or produce errors. This applies to both minutely and daily data.

The SimplePipelineEngine executes pipelines using the following steps:

1. Domain Determination: Determine the domain of the pipeline.
2. Dependency Graph: Build a graph of all terms and their required extra rows.
3. Lifetimes Matrix: Combine domain with AssetFinder to create a (date x asset) boolean matrix of tradability.
4. Workspace Creation: Produce a dictionary of cached/pre-computed terms.
5. Topological Sort: Sort terms to determine execution order.
6. Iterative Computation: For each term, fetch inputs from the workspace, compute the term, store it, and prune unused results to save memory.
7. Output Extraction: Convert workspace results into a 'narrow' format based on the pipeline's screen.

The Pipeline API enables faster and more memory-efficient execution by optimizing the computation of factors during a backtest. It allows you to define a set of factors and filters to screen for assets.

Core components include:

• Pipeline: The main container for factors and filters.
• Factor: Used to transform input data into signals (e.g., rank, zscore, mean, stddev).
• Filter: Used to screen assets (e.g., All, Any, AtLeastN).
• CustomFactor: For user-defined factor logic.
• DataSet and Column: To access underlying data.

To use a pipeline in an algorithm, use attach_pipeline(pipeline) and retrieve results via pipeline_output().

The Trading Algorithm API provides methods that can be called within the following lifecycle functions:

• initialize:
• handle_data:
• before_trading_start:

In these functions, self refers to the currently executing zipline.algorithm.TradingAlgorithm instance.

A Zipline algorithm is defined by two mandatory functions that manage the lifecycle of a backtest:

1. initialize(context): Called once before the simulation starts. Use the context object as a persistent namespace to store variables that need to be accessed across different algorithm iterations (e.g., state, parameters, or indicators).
2. handle_data(context, data): Called repeatedly for each event (e.g., every trading day). It receives the context namespace and a data event-frame. The data object contains the current trading bar (OHLC prices and volume) for each security in your universe.

All core trading functions are imported from zipline.api.

from zipline.api import order, record, symbol


def initialize(context):
    # Initialize state or parameters here
    pass


def handle_data(context, data):
    # Trading logic goes here
    pass

Before running algorithms, you must ingest data into a bundle. Use the zipline ingest command followed by the -b or --bundle flag to specify the bundle name. For example, to ingest the default quandl bundle, run:

$ zipline ingest -b <bundle>

To run an algorithm directly within a Jupyter Notebook cell, first load the Zipline extension using %load_ext zipline. Then, use the %%zipline magic command at the top of your cell. This magic command accepts the same arguments as the CLI. When using the magic, you do not need to specify an input file, and you can assign the resulting performance DataFrame to a variable using the -o flag.

%load_ext zipline

%%zipline --start 2016-1-1 --end 2018-1-1 -o perf_df
from zipline.api import symbol, order, record

def initialize(context):
    pass

def handle_data(context, data):
    order(symbol('AAPL'), 10)
    record(AAPL=data.current(symbol('AAPL'), "price"))