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.
The ScheduledUniverseSelectionModel wraps the new ScheduledUniverse.
ScheduledUniverse is similar to the UserDefinedUniverse we use to create
universes for dopbox/remote files w/ symbol listing. The new abstraction
that 'turns on' this no-data/scheduled based universe behavior is the
ITimeTriggeredUniverse, which exposes GetTriggerTimes which yields the
date/times your univese selection function will be called.
A regression algorithm was also added to cover the new feature.
Implements `Insight.Price` method to make it easier to create new instances of `Insight` of `InsightType.Price`.
Standardize the parameter order to `Symbol`, `TimeSpan`, `InsightType`, `InsightDirection`, `Double`, `Double`.
Three methods were added to enable easier consumption of an enumerable
of slices returned from a history request. The dictionary version is
most likely to be used by python, while the functional versions allow
for lots of flexibility in how you'd like to consume the stream of slices.
After much review, it was determined that this was much more confusing than it
was helpful. The removed implementation hinged on the thinking that the construction
model would be emitting targets as quantities of cash and not quantities of virtual
positions. A previous commit added a warning message for cash modelling and this
commit removes a (bad) attempt at making cash modelling work as expected. For now,
if you want to use cash modelling with the algorithm framework, careful thought will
need to be applied to the implementation of the portofio construction model AND the
execution model. They'll each need to be speaking on the same terms. As of this point,
we're unsure of a means to address all concerns, and so are leaving it as a warning
message coupled with decent documentation in the commit history regarding our
discussions/thoughts on the topics.
Again, the key for cash modelling working properly is just that the portfolio
construction model and the execution model agree on what each target means and
also agree on how virual positions vs currency balances are handled and managed.
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.
The execution models should maintain references to symbol data as long as
the security is a member of at least one universe. It's important to note
here that 'membership' in the universe is not the same as 'recently selected'
by the universe. A security remains a member even after it's been deselected
until it has zero holdings and zero open orders.
In the next commit we'll add an extra condition which will confirm that there
are also zero outstanding portfolio targets for the security.
These methods were phrased in the negative sense. This change
reads how one would expect, if certain conditons are met, then
buy -- vs, if certain condition is not met, don't buy.
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.
1. `HistoricalReturnsAlphaModel`:
1. Adds lookback period for return calculation
2. Adds return-depend direction to insights
3. Refactors indicator history warm-up
2. `MeanVarianceOptimizationPortfolioConstructionModel`:
1. Adds lookback period for return calculation
2. Adds exception for null magnitude
3. Refactors indicator history warm-up
3. Other minor fixes:
1. Default target return was 2 instead of 0.02 (2%)
2. Proper removal of consolidator subscriptions
This framework algorithm alpha model is HistoricalReturnsAlphaModel and the portfolio construction model is MeanVarianceOptimizationPortfolioConstructionModel.
This examples implements an algorithm that rebalances the portfolio according to modern portfolio theory.
This method is misleading at best and incorrect at worst.
Insight objects should use reference equality or compare ids to
perform equality checking. The only usage, in MacdAlphaModel,
was easily converted to not relying on this method.
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.
- Adds log to display the python version the algorithm is using.
- Fixes python algorithms that were failing because of small subtleties
like leading zeroes.
- Updates pythonnet with a version compiled with python 3.6 flags
- Changes in DockerfileFoundation: we now use miniconda to manage the python
environment.
- Took the opportunity to add NTLK (#1349), Tensorforce (#1369) and
PyTorch/Pyro (#1385).
- Changes readme in Algorithm.Python to show steps to install miniconda
AlexCatarino