Fix behavior in minute mode history with frequency `1d`, where on the
day immediately following an adjustment action, the overnight adjustment
would not apply. (However the adjustment would be applied after a 1 day
lag.)
The root cause of the bug was that the history data for minute mode when
using `1d` stitches together a sliding window of the daily data for
previous and the current minute. That daily data sliding window and
corresponding adjustments was being read as if the data was being viewed
from on the last day of the window; however in this case the data is
being viewed from the day after the window has completed. The difference
in view points requires the adjustments to popped and applied by the
adjusted array one index earlier. The fix uses the `extra_slot` value as
signifier on whether the data is being viewed on the following day and
then accordingly adjusts the index of the mulitpy object.
Also, change the split and merger test data ratios to have different values,
to ensure that different adjustment values are applied; as opposed to
doubling up on just one of the values.
ENH: fast stochastic oscillator added.
A fast stochastic oscillator has been added to the technical
factors. This is the simplest of the stochastic oscillators,
and can be used to build the others.
Tests have been added that compare against the values expected
from that of ta-lib STOCHF.
FastStochasticOscillator is marked as window_safe=True to allow taking
moving averages for smoothing.
The file format converted by this script has no support for reading in
Zipline. Remove since it requires import of a library not defined in
requirements.
Make the delineation between `DailyEquityHistoryTestCase` and
`MinuteEquityHistoryTestCase` whether or not minute dts or daily dts are
used as the query timestamp, instead of whether the frequency is `1d`
vs. `1m`.
Preparing for adding a repro case for where using `1d` with minute data
fails when there is an adjustment occuring the day before the query
minute dt.
When writing first_trading_day, it is already in the correct frame of
reference (seconds since epoch) and does not need to be transformed
further. Adjusts the reader to expect this value.
Instead of inferring it from the minute/daily writer, we now require the
first trading day to be passed explicitly, so the creator of the
DataPortal controls what is used as the first trading day.
Allow `WithBcolzDailyBarData` to opt-in to reading data defined by
`WithBcolzMinuteBarData`, so that the daily and minute test for the same
asset and dts correlate between the two readers.
The correlation is relevant for history tests which blend daily and
minute data.
Also, make the test data for the split and mergers assets in the minute
suite align at the thousands place if the adjustmets are applied
correctly, by starting the prices with a base of 4000 and then halving
the start value each day.
jfkirk