With this patch, on the close of markets we "fast forward" to midnight of the
next trading day and calculate the dividend payments. This patch assumes that
the dividend dates are all at midnight UTC.
For the case where the window isn't covered by the data streaming
through the simulator.
e.g. in a case where the stocks being iterated over change every
quarter, the supplemental data will fill in the 'gap' missing from
the transform since the 'new' stocks were not streaming before
the beginning of the quarter.
Of note, test cases are covered by internal suites, but this could
use tests with completely mocked data.
- Removes New Year's on Saturday, in that case there is no New Year's observed.
- Adds Monday after a July 4th Sunday
- Adds Friday before a July 4th Saturday
- Adds Monday after a Christmas Sunday
- Adds Friday before a Christmas Saturday
Algorithm returns and the risk calculations that depend on them now include
cash dividends. This commit does _not_ provide an API for user algorithms to
access dividends.
PerformanceTracker expects the dividend data to arrive as events, similar to
the way that Trades arrive. Dividends are expected to have adjusted payment
amounts that are inline with adjusted trades.
PerformanceTracker maintains state of all the unpaid dividends in the position
objects held in PerformancePeriod. Dividend objects contain all the relevant
dates (declared, ex, payment) as well as net and gross amounts. Dividends are
removed from the list as they are paid. Cash flow is not incremented until the
payment day. This creates the possibility of a dividend being owed but not
paid or realized before the end of a test. For example, a dividend with an
ex_date of today may have a pay date 2 weeks in the future. Right now the
algorithm does not receive any credit for unpaid dividends.
Tests cover buying/selling around the ex_date and payment_date, and checking
that the performance calculated is as expected.
So that algorithms that specifiy market_aware, days and delta
as args can be transitioned to just specifying a window_length kwarg.
Moving towards removing market_aware and delta completely.
The eventual goal is to remove the market_aware and delta kwargs,
but removing the kwarg completely would break the init
method of EventWindow based classes for existing algorithms.
In the meantime, this ensures that only market_aware is only ever
set to True and raises an error if it is False.
Also raises exceptions if values are set for delta, which was only
used if market_aware was False
Also, since the logic for checking window length is changed,
because in market aware mode we should always be checking the
window length, this adds some sanity checking to the window length.
Changes these tests to use market_aware==True, so that unit tests
follow the same code path as actual execution.
All use of EventWindows against data follows market_aware behavior.
These tests are the only use of market_aware==False, so heading
down the path of removing market aware completely.
Takes the value set for a variable on handle_data and records it,
e.g.:
```
def initialize(self):
self.incr = 0
self.record_variables(['incr'])
def handle_data(self, data):
self.incr += 1
```
Would record a variable of `incr`.
Emits the recorded variables as part of the daily performance.
This batch combins work from:
Thomas Wiecki <thomas.wiecki@gmail.com> (@twiecki)
fawce <fawce@quantopian.com> (@fawce)
The trading day index is all business days in range minus the
non trading days we are already calculating.
Also, uses trading calendar indexes for batch transform, since the
batch transform was the only use of non_trading_days.
Instead of constantly adding and removing holidays to do market
day delta math, uses pandas DatetimeIndex to get the index of the dates
and uses the index difference to calculate market days.
The test factory was creating non-market days.
i.e. the date range spanned the weekend.
Using pandas' BDay frequency so that only business days are created.
This specific date range doesn't have holidays, so not accounting
for holidays in the factory.
Also, widens the range of the trading calendar to cover the test dates
generated by the factory which include 1990.
Previously the trading calendar began with 2002, meaning that holiday
and weekend adjustments with the data exercised by the factory did
not trigger when run with data in 1990.
This does increase the memory footprint of the tradingcalendar module.
However, only by a couple MB, so taking the hit there to enable
correct behavior.
These tests ensure that there are three, not two, empty values
at the beginning of the transform.
Also, ensures that we are using a window length of 3 on the tests.
So that wordings of errors,etc. match the window length.
Tim