In the performance period the max_leverage, max_capital_used,
cumulative_capital_used were calculated but not used.
At least one of those calculations, max_leverage, was causing a
divide by zero error.
Instead of papering over that error, the entire calculation was
a bit suspect so removing, with possibility of adding it back in
later with handling the case (or raising appropriate errors) when
the algorithm has little cash on hand.
Check for whether or not the index's timezone is UTC or not before
attempting to localize, since an already localized index throws an
error when tz_localize is called.
Pull in patch that fixes the stop orders so they behave correctly
with regard to the price being greater or less than the stop for both
buys and sells.
Also, update unit test and add a refactoring on top of the fix to
make each sell/buy, stop and limit combination more clear.
Instead of nesting order direction and related stop and limit logic,
derive a bitwise mask from the combination of order configurations
and use the mask as a 'switch'.
So that we can more clearly demarcate each case of buy/sell and
price compared to stop, and their expected outputs.
Also, add comment about the current behavior versus the behavior
that will be moved to in an upcoming fix.
Remove the lists of DailyReturn objects in favor of using pd.Series
to store the return values.
Should make it easier to inspect the values when stepping through,
make the windowing of data to a certain range more facile by using,
and have some performance increases due to removing object creation
and member access.
This reverts commit 17b8980fb9.
Backing out rigidness of market and close, while sorting out how
to handle events that are not on a day in the trading calendar.
Instead of creating the market open and close mid-simulation,
calculate upfront the values for market open and close in a
DataFrame, so that they values can be looked up by date, as
viewed as series while investigating data issues.
One downside of this implementation is that the entire history
has open and close values calculated, even though the simulation
may only be a subset of the trade data on record.
Should consider moving the `times` property and other methods
that care about the start and end date of a simulation to
SimulationParameters or another like object.
Instead of using all calendar days between start and end in test
sources, use the trading calendar for test sources.
Needed for an incoming refactoring of market open and close,
where the opens and closes are indexed by market days.
The underlying RollingPanel in batch_transform was always accumulating
all values to ever appear in data.
However, at any given algo time the desired return value is what the
current active sids are.
Instead, mask down to the sids that are passed in as the data parameter.
These tests use the random simulation parameters, which is leading
to an intermittent failure.
We may want to consider removing the randomness, but in the meantime
the randomness is exposing a case where the cost basis is not the value
expected, so logging the sim parameter values to help track down what
parameters cause the failure.
So that with minute data, 2.5 orders of magnitude of data can
be cut, allowing for longer window_lenghts, when the daily
values are what are desired for a signal.
So that the units match the other risk calculations, also
use annualized returns for beat and alpha.
Update answer key to match values calculated on the first day.
Also, update performance tracker test so that the returns used
are fractional instead of > 1, so that the annualized numbers are
more in line with real world values.
This could perhaps be labelled BUG, as well.
Change the Sharpe (and algorithm volatiilty) value used to compare
algorithms/backtests so that it is annualized and uses daily returns.
Previously, the Sharpe metric was using the same calculation style
as the fixed size periods, i.e. 3 Month, 6 Month, etc., which can
use the geometric mean when comparing against the risk free.
Change the Sharpe calculation to use the arithmetic mean differenc
against the risk free rate, using daily (non-compounded) values.
Also, use annualized mean returns.
Hold on to the values set for the returns frequency and the cont
index, mainly for debugging purposes mid-process.
It was useful to have these values when debugging why there was
an extra non-midnight time in the index.
Eddie Hebert