One year NYSE test that buys a lot triggers 492,963 calls to
minute_to_session_label. Only 98924 ~(390 * 252) make it past the
cache and trigger the heavier computation.
Remove module scope invocations of `get_calendar('NYSE')`, which cuts
zipline import time in half on my machine. This make the zipline CLI
noticeably more responsive, and it reduces memory consumed at import
time from 130MB to 90MB.
Before:
$ time python -c 'import zipline'
real 0m1.262s
user 0m1.128s
sys 0m0.120s
After:
$ time python -c 'import zipline'
real 0m0.676s
user 0m0.536s
sys 0m0.132s
They're not meaningful, and they cause warnings from numpy.
Implemented in terms of a new preprocessor, `expect_bounded`, which
takes a tuple of `upper_bound` and `lower_bound`.
The new TradingCalendar method is called `minute_index_to_session_labels`.
It takes a DatetimeIndex of in-order market minutes and returns a
DatetimeIndex of the corresponding sessions.
The new method is approximately 100x faster than mapping
`minute_to_session_label` over a large DatetimeIndex.
Encapsulate the shared global calendar map in an object.
This allows consumers that don't want to participate in custom
registration to pass around a calendar dispatcher, and would make it
easier to support contextual management of the global calendar map if we
want to do that in the future.
As a bonus, we now only create one instance of each calendar, instead of
one per alias.
Previously, run_algorithm caused an error if run on raw (non-bundle)
data, because of uninitialized variables. Initializing those variables
to None to allow run_algorithm to work with Panel data, etc.
Also, run_algorithm did not create sim_params for the TradingAlgorithm
instance it created; this kicked the can to TradingAlgorithm, which
gets default sim_params with data_frequency 'daily'. To support minute
bars, changing run_algorithm to create its own sim_params with the
data_frequency specified in its arguments.
Changes the overlap behavior so that it is an error to write data which
would have two companies holding the same ticker. Other than one test
around which company would win in that case, all the other tests are
passing. That single test has been changed to check the write-time
error.
* BUG: Further corrections for days_at_time
- Revert to using DateOffset, as Timedelta doesn't handle offsetting by
one day over a tz change properly:
In [12]: pd.Timestamp('2004-04-05', tz='America/Chicago') + pd.Timedelta(days=-1)
Out[12]: Timestamp('2004-04-03 23:00:00-0600', tz='America/Chicago')
In [13]: pd.Timestamp('2004-04-05', tz='America/Chicago') + pd.DateOffset(days=-1)
Out[13]: Timestamp('2004-04-04 00:00:00-0600', tz='America/Chicago')
By creating a DateOffset using the `days` kwarg, the issue previously
fixed in bcc867b is addressed.
- To preempt any other pandas issues around day offsets, changes to
performing these with no timezone, then localizing to the local
timezone when shifting the time.
- Adds unit test for days_at_time
* STY: Remove unused import
Prior to pandas 17, there were issues with offsetting dates with
DateOffset around discontinuities (like the start of DST). We can use
Timedelta here instead, which handles these edge cases.
Jean Bredeche