This was always logging, even when the risk model wasn't overriding
any of the targets. The new check checks to see if the risk model
created any override targets, and if so, we'll print all of the
targets as they will be submitted to the execution model.
This identifier is used to determine the alpha model that generated.
This is NOT ideal, since it requires users to specify the value, more
thought will be givent to how we can resolve this value automatically
Adds test for surviving roundtrip copy operation.
The current targets are passed into the risk model for risk assessment.
The risk model is only required to return any changes required from the
point of view of the risk model. The risk adjusted targets are given
priority, and if no risk adjusted target is specified for a symbol than
the target produced by porfolio construction will be used.
Cash modelling poses several unique problems w.r.t the algorithm framework.
One constant issue is that our primary cash brokerage, GDAX, doesn't support
the concept of virtual positions. Another issue is the very concept of a
vitual position. In cash modelling, there are no virtual positions, just
currencies. In this model an issue is how do we phrase portfolio targets.
For example, if I emit a target of 10 BTC/USD but don't own an USD, what
does that mean? I might have millions of dollars of LTC, but since I don't
own any USD I won't be able to execute on BTC/USD. A smart algorithm might
sell some LTC for BTC instead. At this point, we're getting into the nitty
gritty of an individual algorithm and how that algorithm might transition
between various currencies. The framewor absolutely supports these types of
things, but it requires agreement between the portfolio construction model
and the execution model as to exactly what a target is describing. In the
margin world, a target on BTC/USD simply means to change your virtual
position in that currency pair, but in the cash world, I could see it meaning
a direct amount of BTC (or USD depending on target direction +/-).
TL;DR -- Add a warning describing potentially unexpected behavior with the
open source models as written.
When removing a security from a universe it's important to ensure that there
is not an outstanding portfolio target for that security that hasn't been
reached yet. A common pattern is (or should be) in the portfolio construction
model's OnSecuritiesChanged, emit a zero portfolio target for that security to
instruct the execution model to liquidate any holdings. Since the execution
model might not submit an order immediately, we need to be sure not to remove
the data subscription in UniverseSelection.ApplyUniverseSelection until we're
sure that the zero target has been reached.
In support of this, we've added the target to the security's holding class an
update it as part of the framework infrastructure. The universe selection
infrastructure can then query the security's current target to ensure that it
either doesn't have one (null) or that it is a zero target. This new condition,
coupled with the existing conditions (no holdings/no open orders) is sufficient
to guarantee that we're not removing security data subscriptions while they're
still needed by framework modules.
NOTE: This implementation was written under the assumption of using margin based
accounting and NOT cash modelling. We'll possibly need to revist these checks
when we move to fully support cash modelling within framework algorithms. The
next commit will prevent the VWAP/STD execution models from even attempting to
work under cash modelling.
VWAP will submit market orders while the current price is more favorable than VWAP.
STD will submit market orders while the current price is a configured number of
standard deviations away from the mean in the favorable direction.
Adds method overload that accept a `PyObject` to `SetAlpha`, `SetExecution`, `SetPortfolioConstruction`, `SetPortfolioSelection` and `SetRiskManagement`. In these methods, a custom model written in python will be wrapped around the respective `PythonWrapper`.
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.
If we make a prediction for 1 day in the future, we actually mean 1 trading day.
This change updates the alpha analysis logic to take into account the security's
market hours.
This is to prevent derived types from overriding these implementation as
they're critical to the proper function of the class. This removes the
existing reflection checks that would accomplish the same thing, but at
runtime instead of compile time.
This abstraction point is completely unwarranted. The signal object is really
just a DTO and it's extensible as it is currently defined. This also allows us
to enforce certain behaviors, such as internal set of GeneratedTimeUtc.
Removes GeneratedTimeUtc from the result object as it's now directly on the signal.
IAlgorithm.FrameworkOnData is used to pulse models with new data each time step
IAlgorithm.FrameworkOnSecuritiesChanged is used to pulse models with security changes
These two functions need to be separate to ensure that if we add an indicator during
the securities changed event that it will get the data from the current time step.
This forces us to call the securities changed event before we invoke the consolidators
for the current time step.
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.
Framework algorithms are expected to set these models. All of these models
should be user specified. The execution model could be defaulted to the immediate
model, but perhaps it's best that users are explicit
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?)
Michael Handschuh