diff --git a/docs/extensions.rst b/docs/extensions.rst deleted file mode 100644 index 4f4cc936..00000000 --- a/docs/extensions.rst +++ /dev/null @@ -1,93 +0,0 @@ -********** -Extensions -********** - -.. highlight:: cython - -Philosophy -========== - -Use judgement when to use C extensions. Debugging them potentially -has a time cost of t=infinity, they can segfault, and may not be -debugabble by anyone else. Simply put 90% of the time its not worth it -and construction of extensions be must informed by scientific profiling. -Listen to your inner Knuth. - -Writing C Extensions -==================== - -Caveats aside, C Extensions can be in two forms: - -- C -- Cython - -Cython is a superset of Python which compiles into C. The code it -produces is generally not human readable. - -Reference: http://docs.cython.org/ - -C is well, C. You manage your own memory and interface with Python.h . -If you need raw performance or need to interface with other C libraries -this is often the best approach. Of course this requires that you -be very careful to tend to memory and and Python's internal garbage -collection. - -Reference: http://docs.python.org/c-api/ - -One can write C++ extensions, but please don't. - -One could also embed Assembly in C and thus in Python, but again please -don't. - -Compilers -========= - -Compatibility - - - Do not use Clang - - Do not use GCC-LLVM - -Use standard GCC >= 4.6 from gnu.org, otherwise extensions will have -undefined behavior and will not be portable. - -Also make sure to code against Python 2.7 and numpy 1.6.1 header -files. If using Cython have it auto figure out the paths to ensurable -portability. - -Pure C -====== - -.. highlight:: c - -:: - - #include "Python.h" - -Releasing the GIL -================= - -:: - - from libc.stdio cimport printf - - with nogil: - # in here you allowed to do whatever you like so long as - # you do not touch Python objects. This really should - # only be used to interface with other C libraries. - - printf("hello, world\n"); - -Debugging -========= - -Compile with debug symbols and use gdb and valgrind. It sucks but its -really the only way. - -Vim -=== - -.. highlight:: vim - -For syntax highlighting in Vim:: - - :set syntax=pyrex diff --git a/docs/index.rst b/docs/index.rst index 9151c79c..504e0dbb 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -54,9 +54,7 @@ Contents installation.rst quickstart.rst contributing.rst - overview.rst modules.rst - extensions.rst Indices and tables ================== diff --git a/docs/overview.rst b/docs/overview.rst deleted file mode 100644 index 9d7d3ad5..00000000 --- a/docs/overview.rst +++ /dev/null @@ -1,77 +0,0 @@ -******************************************* -Overview -******************************************* - -Simulations -=========== - -:mod:`zipline` runs backtests using asynchronous components and zeromq messaging for -communication and coordination. - -:class:`.algorithm.TradingAlgorithm` is the heart of :mod:`zipline`, and the primary access point for creating, -launching, and tracking simulations. You can find it in -:py:class:`~zipline.algorithm.TradingAlgorithm` - -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 --------------------- - -According to `this post -`_ on the Quantopian -forums, time periods during which none of the selected SIDs were traded are -skipped. - - -Review the unit test coverage_. - - - -.. _coverage: cover/index.html