Fixes a bug where we were using the security's data resolution to compute
the insight's close time. This led a case such as insight.Period == 20days
to step 20days worth of tradable minutes (assuming minute data resolution),
yielding a close time that was very far in the future.
We also add different means of specifying an insight's period/close time:
1. Specify insight period as a TimeSpan and we compute close time
2. Specify insight period and a resolution and bar count and we compute close time
3. Specify insight close time local directly and we compute the insight period
The key here is maintaining consistency between the three different approaches
which is heavily validated with the corresponding unit tests.
Edits also made to trust the insight's close time as the analysis end time in
the case where the analysis period == insight period (extra analysis period = 0).
Given the current setup (extra analysis period == 0), this guarantees that close
and analysis end times are equivalent.
Regression statistics were updated and expectedly we get many more insights that
have completed analysis, and as such, average scores have also changed.
This flag indicates whether or not the local regression test system,
via RegressionTests.AlgorithmStatisticsRegression should run a given
IRegressionAlgorithmDefinition
It's important that we keep the factor files consistent with respect to
the date that they were generated. This enables us to run the regression
algorithms in the cloud and get the same results by using the factor files
from the correct date.
A mechanical refactoring was performed to make algorithms currently used in
regression algorithms to implement IRegressionAlgorithmDefinition, which allows
algorithms to define their own expected statistics and what languages should be
run as part of regression. The type name of the C# type is used to determine the
file/model name for python. This was for simplicity, but if needed, could later be
refactored to expose more information, but for now the convention of keeping names
the same makes sense and just works easily.
- Use `MaximumDrawdownPercentPerSecurity` as `RiskManagementModel`.
- Modifies regression test to reflect risk model choice
- Use SetXXX to set models in python version
The term 'alpha' is used to describe the entire algorithm. Therefore, 'alpha'
produces insights. From this we have things like IAlphaModel, which is the model
defining how insights are produced. We have IAlphaHandler, which defines how the
insights from a single 'alpha' (the algorithm) are managed, analyzed, and stored.
Types closer to the individual prediction level, such as InsightDirection, or
InsightScore relate directly to exactly 1 insight. The distinction between the
two became more clear as we developed the insights API, and from that effort it
was decided to harmonize alpha/insight terminology across the various QC systems.
Requiring a period here forces signal models to place a time frame on
when their signal is valid. This also allows consumers of signals to
have some expectation of when a prediction should come to fruition.
The risk management model is intended to check the algorithm's positions
at the end of each time step to potentially exit positions that are losing
too much.
This change includes a check to prevent users from overriding methods required
by the framework. This is non-ideal and we should perhaps look into alternatives
to this approach, which could involve additional methods on IAlgorithm. In order
to not lose access to these events at the algorithm level, we could expose them
as C# events (not sure python compatibility?)
Martin Molinero