Instead of using a pandas Series of with dictionaries as the
values treasury curves, use a DataFrame which more naturally fits
the data type of a having a timeseries with mulitple values.
Should allow easier slicing/manipulation of the treasury curves,
e.g. getting 10 year curves would now be:
```
treasury_curves['10year']
```
Before we were setting benchmark returns on the first day
to 0. This commit changes this by calculating the benchmark
return from open to close.
According to @eherbert this is also what the answer key does.
zipline.__version__ is now present. Closes#94.
Moreover, git master should have a .dev version string according
to convention. Releases then get the .dev label removed.
Also remove test that compares risk metrics batch to iterative,
since the 'iterative' calculations, replaced by the cumulative
calculations, will intentionally drift from the results in the risk
report due to annualization and other factors.
Work towards having separate calculations for the fixed periods versus
the cumulative/headline risk metrics.
Different sumbodules for each type should help make the calculations
type distinct and easier to find.
In anticipation of splitting apart the different risk classes
into their own submodules, a distinct risk module should help
organize those new classes.
For consistency, datetimes returned by the trading calendar should
always show HHMMSS of midnight UTC. Not only is this useful for
consistency, but it also allows us to check if a particular date() is
in an array of these datetimes, because they will hash to the same
thing. For example:
early_closes = get_early_closes()
... later ...
if current_bar_datetime.date() in early_closes:
... today closes early ...
If if the datetimes returned by the trading calendar functions don't
have 00:00:00 for HHMMSS, then the "in" check above will fail because
the date and the datetimes in early_closes won't hash to the same
thing.
If a stock stops gettign updated values, e.g. if a stock rolls out
of a universe strategy, currently the underlying batch transform
for TALib may have nans (which is another issue that could be addressed),
the nans cause crashes when passed to some TALib function, e.g. Bollinger
Bands are incompatible with all nan values.
So, drop sids that only have nan values for the current data panel.
The defaultdict behavior was allowing both algo code and
TradingAlgorithm wrappers to add unintended keys.
Remove use of defaultdict in favor of a dictionary that explicitly
adds the values in tradesimulation, otherwise allow a KeyError
if the bar is indexed with a sid that doesn't exist.
Also, when iterating over the keys in the data bar, only return
those keys that have pricing data.
The deepcopy of events into the EventWindow's ticks was causing
a significant increase in memory consumption, e.g. an algorithm with
almost 200 sids and 14 vwaps removing the deepcopy reduces the amount
of memory consumed by about 40%.
The downside is that if an event's properties are changed, which is
not advised, later on, then the signal derived from vwap etc.
may be changed.
Fix the spreadsheet to apply a factor of COUNT / COUNT - 1
to the COVAR value.
Also, go back to using the C[1][1] index instead of calculating
var independently.
Use recent change to benchmark variance in the beta calculation,
instead of referring to the 4th quadrant of the covariance.
Also, read answers from answer key for corroboration of beta values.
The np.cov call needs a ddof of 0 to match the answer key, which uses
Excel's VAR.
When switching np.cov to use a ddof of 0, the benchmark variance is
no longer the 4th quadrant of the cov result, so use np.var directly.
Fix warnings when compiling the docs.
Removes the documentation of the default types, which already gets
included automatically and was wrong because not kept in sync with the
function signature.
Changed, the formatting to the Sphinx formatting.
This looks much better in the compiled documents, but does make the
source a bit harder to read.
This reverts commit e3a9ca27b1, reversing
changes made to 3d8bdeb429.
Conflicts:
zipline/gens/tradesimulation.py
The aforementioned change needs a revert because it caused a 'doubling'
of orders, since the portfolio is not updated until after handle_data
is called a second time after an order has been processed.
The flexibility of fill_delay is still desired, but remove for now,
favoring reverting back to existing behavior over trying ot fix the
fill_delay logic.
A multi-stock TALib transform was returning the same value for
all stocks, specifically the value for the first stock in the panel.
Index into the datapanel using `sid` instead of using the `[0:]`
index which was used when only supporting one sid.
To support mulitple sids the TALib transforms now return a dict,
instead of a float. Accordingly, the TALib example script now needs
to index into the transform result.
The TALib transform only supported operating on the first value
of a given batch transform panel row.
Instead of returning the one value, even if an panel with multiple
sids was provided, return a dictionary that maps stock to TALib
result.
Prepare for making the zipline_wrapper operate on multiple sids,
as the needed nested logic will get cramped within the nested function.
Also, should help clearly define the inputs of the zipline_wrapper
function that are needed before it is passed to the BatchTransform
constructor.
Set the `compute_only_full` to False so that the 'is window full' logic
is delegated to the TALib's lookback function.
If the window is not full to the `timeperiod` or other lookback setting,
then TALib returns a `np.nan`.
Also, fix the bars/data_frequency not being passed to the BatchTransform
init.
This further shows need to create a minute test for TALib transforms.
Provide a default value for data_frequency, choosing 'daily',
so that the fill_delay is set even when a data_frequency value
is not in kwargs.
This does open up a place for disjointedness if the sim_params that
is passed to run does not match the data_frequency set during initialize.
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.
Eddie Hebert