Also, add direct coverage of last_traded_dt in the `test_data_portal`
module.
Prepares for adding test coverage of `get_last_traded_dt` for `Future` assets.
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.
Change the mock minute data to no longer use an increasing arange, so
that a days worth of minute data can be summed and fit inside of a
uint32.
This change was required because of working on new test data that looked
like [0, 100, 200, 0, ] which was resulting in a daily rollup of 0 data,
when the coverage needed a non-0 value.
Also, factor out the resampling function, with an eye on a making it
easier to convert from minute bars to daily bars during ingest/load
processes.
When adding fixtures for futures data, there will be a need for multiple
calendars in the fixture ecosystem. e.g. a test that includes both
equities and futures would need an overall calendar which encompasses
both equities and futures; however, the test data for equities should
still still be limited to the bounds set by the NYSE calendar.
Make the fixtures that setup trading calendars and values dervied from
the trading calendar (e.g. trading sessions) accept an iterable of
calendars which need to be created, then populate those values into a
dict keyed by the calendar name.
Change `WithNYSETradingDays` to include sessions in the name,
since we are moving to session as the name for the 'day' unit.
Provide `trading_days` which is really "NYSE trading sessions` on
`WithTradingSessions` for backwards compatibility.
Previously, on the dt of a capital change, we use the un-updated
prices to find the ending performance of the previous subperiod and
then got the new prices to determine the portfolio value used to
calculate the delta, without actually updating the performance
before applying the capital change. This logic is confusing and
unintuitive. Instead, save the ending performance as we do previously,
but have temp values for the starting current subperiod value.
Update those temp values after processing the capital change
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.
TradingAlgorithm.run didn't support Panel minute bar data, and assumed
all Panel data was daily.
To rectify this, adding PanelMinuteBarReader class.
TradingAlgorithm.run decides whether to use it or PanelDailyBarReader
by assuming data is daily if and only if the time of day of every
Timestamp is identical.
Jean Bredeche