Add a `bars` keyword arg, as is used with BatchTransform.
Also, instead of overwriting the window_length kwarg with timeperiod,
always use the lookback value from the created TALib function,
as timeperiod will be an input into that value if it exists.
Calculate `window_length` in minute mode so that there are enough
days to cover the minutes in the timeperiod.
For the creation of a TALib transform use timeperiod intsead of
window_length, to be more in the style of TALib usage, since all
TALib functions may not ending up using BatchTransform, so start
the practice of adhering to TALib conventions to make porting and
explanation easier.
The loader module printed some warning messages, these could
be changed to use a logger, but for now convert to use the print
function for compatibility with Python 3.
Python 3 requires using dot syntax for relative imports,
otherwise the import is treated as an absolute import, i.e.
an import of a module from outside of the project.
By using dot syntax now, imports should be compatible with both
Python 2.7 and Python 3.
Looking forwards to Python 3 capability, maintaing code that uses
iterkeys would require some overhead of checking what Python version
is available etc., instead use a DatetimeIndex so there is no need
to use key iterators, reverse, etc. on an OrderedDict, as the
DatetimeIndex allows 0 and -1 index, as well as the needed fast `in`
functionality.
This VagrantFile will, on "vagrant up"...
- Create a simple, minimal Precise Pangolin (12.04) Ubuntu 64 bit VM
- Customize the VM with 2 virtual CPU's and 2048MB of RAM
- Configure SSH for passwordless access (from the command-line)
- Add the required packages from the Ubuntu repo to support zipline
- Add (and compile) ta-lib
- Add the required Pip packages
When Vagrant is done, you can start hacking on zipline with:
vagrant ssh
cd /vagrant
python {some python script that uses zipline}
In the spirit of making this a disposable dev environment install
everything in site-packages.
"nosetests" and "examples/dual_moving_average.py" both succeed
after the configuration finishes.
The "use_environment" decorator is too side-effectful (e.g.,
connecting to Yahoo! Finance or another data source) to be used as a
decorator to a function that gets evaluated during module load. This
causes problems, e.g., if Zipline is being used in a gevent
environment, when the trading environment created by the decorator
argument tries to use greenlets when gevent hasn't been fully
initialized.
Since the decorator is nothing more than a context-manager wrapper,
this commit removes the decorator and replaces its use with contexts,
i.e., "with" statements.
Raise exceptions when the slippage model returns transactions
that are non-sensical, i.e. those with zero volume, buy transactions
when the order is a sell (and vice-versa), and transactions that are
for a larger amount than the corresponding order.
TODO: After adding a unit test suite that covers just the blotter,
add tests that exercise this logic to that suite.
Instead of searching through the open orders to find the ones
that match the current transactions, now that simulate returns
the pair of transaction and order for which that transaction
was created for, that order can be used where we previously
searched for a modified order.
This should be a runtime improvement since, but not yet verified
via thorough profiling.
The TALib related tests randomly fail, skip for now, as it causes
noise when developing against the latest versions of the codebase.
Should remove skips when TALib is closer to being fully supported.
So that blotter.process_trade doesn't need to reindex the dictionary of
open orders, yield a tuple of (order, transaction) from simulate.
Also, update corresponding unit tests now that the method returns
a generator instead of a list.
Instead of using copysign with a param of 1, use `abs` to make the
code more clear between when slippage is using the absolute value,
and when it is creating an amount that uses the order direction.
To make implementing a custom slippage model more straightforward,
provide a simulate method that will setup the calling of
`process_order`, which individual slippage models override to
do the unique slippage handling, where the simulate method handles
the boilerplate of checking order triggers, etc.
In the volume share slippgae, the current amount had the direction,
i.e. buy/sell was baked into the value of `cur_amount` which then
needed to have the direction multiplied out when parts of the slippage
model needed to take in just the magnitude/amount into account.
So calculate the current volume, use that in calculations and then
apply at the order direction at order time.
Also, when applying the direction to the magnitude of the sell,
use copysign to make the code more explicit about taking the direction
of the order, instead of it possibly having some scalar impact.
As well as remove direction from volume_share calculation since that
calculation and subsequent calculations only care about the magnitude,
so make the disregard for direction more explicit by removing it.
Since `cur_amount` before it's changed by the direction, is always
a positive value, multiplying it back by the direction should also
always be positive.
Found that when implementing different slippage model, needed the
open amount in several places/functions, having the open amount
as a property of an order should help reduce the need for passing that
around and maintaining the value separately.
instead of just limiting it with max_date. This allows for an
additional "live" day appended to the end, fixing various uses
of the trading_day_map, and replacing the isolated check in
get_next_close.
- Change the expected type for order information from the string
of the order id to an `Order` object, so that it matches the same
abstraction level as passing in an event.
- Change the order (not to be confused with the parameter named `order`)
of the parameters so that they go from left to right in order of
static -> dynamic, i.e. the parameters most likely to change within
each invoration are the amount and price, with amount more likely
to change than price.
create_transaction accepted both sid and order, which in all cases
was derived from the current event, so remove `sid` and `order`,
replacing them with event
If there is a scenario where sid and order need to be set independently
of each other, then the underlying Transaction object can be called
directly.
Looking towards making writing custom slippage models slightly easier
by removing the redundancy.
Work towards a set_slippage method accepts a function that takes
event and orders as the argument, instead of being tightly bound
to using classes like FixedSlippage etc., in that scenario the
instances of SlippageModel will be used via `__call__`, so that
backwards compatiblity is maintained.
Eddie Hebert