carterbain/alephnull

A python module for algorithmic trading and strategy validation

alephnull's Issues

Is our repo open source friendly?

Open Sourcing the right way

More functional oriented

I am not a big fan of OOP, therefore over the long term if we can devise away to use the module in a more functional manner that would be awesome. Especially for research in the notebook, open code is much easier to work with as debugging at the class level is tedious. I am being vague here on purpose, as I am not sure what I want, I think this will really develop over time.

Pandas is really intuitive when it comes to instantiating an object, in such a way that it really gets out of the way. Look at DataFrame, Series, groupby, etc

Handling Roll Over

We need to decide on a methodology for rolling from one contract to another. While simply generating a continuous contract is the easiest, I don't want to do this if it doesn't reflect the transaction costs and roll yield. Another alternative, might be putting together a hierarchical data structure with all the contracts (memory intensive) and providing a method within the TradingAlgorithm to determine rolling over such that the trade is accounted for including transaction costs.

Plot Module

Eventually I would like to have a plotting module, with some builitins for strategy diagnostics. ie Event Studies, and some variations thereof. Also performance attribution, and generic entry and exit plots for the trade universe.

Efficiency on large datasets

As far as cacheing data, a compromise between a huge inefficient DataFrame and SQL might be HDF5 (pytables). This can provide hierarchial data storage on the drive freeing up memory and allowing for querying through pandas. Please do some research.

Heres a few links to get you going:
Fast Data Mining
HDF5 Pandas cookbook
Pytables
Large Datasets

Handling Cash Flows

How do we handle when clients add money to our fund or conversely, withdraw. This needs to be handled in such a way that a client redemptions are not influencing performance reports. As if we simply subtract from the portfolio value, it will show as a substantial drop in our strategy not attributable to performance.

Account management and sanity

Stock zipline doesn't have any sanity bounds on leverage, this must be addressed before live execution. Builtins should be added to handle this, I wrote some code on quantopian that you can likely work from, at least for equities. Some hacking is gonna be necessary for futures products.

My long only code

Long/Short

On the Cloud

If we are running a strategy on the cloud (probably picloud or EC2), is our data feed going to break?

Change filenames and namespaces

We need to eliminate future confusion and safely go through renaming all zipline files.

I would like an import convention similar to numpy or pandas ie.

some permutation of
import alephnull as a0
import anaught as an

whatever best complies with PEP, and doesn't interfere with builtins.

Data

We need to get live data feeding into the module, if we cant pull historical data from IB, we need to add another high frequency data source for back testing. Maybe

Also, we need to determine an aggregation method of the data that our algorithms can still process in real time (1 sec, min, hour?)

Source to scrape contract details

We need a reliable data vendor to provide details on the contracts we trade/backtest, (tick size, contract size, margin, etc). This optimally would be automated, nobody is crazy about data entry. IB might have this in meta data?

Handle Futures Properties

The module needs to be cognizant of the different properties of contracts when calculating profits and losses, and gains as a percentage of margin.

Map the API

All the existing zipline functionalities need to be mapped to the IB API for seemless implementation

Trade Allocation

In back tests and paper trading you have a single account that you test a strategy on. Conversely in Live Trading there will be many client accounts, depending on how things are structured this could be quite difficult. Optimally we will have a single trading account with aggregated funds for trading, and then upon trading make one order for all accounts and then aggregate the shares/contracts to the owners account by the end of the day. Perhaps we can have a side process that monitors the trading activity, and upon fill breaks the order down by percentage ownership and auto allocates the order.

If we are incredibly lucky, this operation might be included in the IB API
IB trade allocation manual

Map the API

All the existing zipline functionalities need to be mapped to the IB API for seemless implementation