- Typoes were fixed in `ImmediateExecutionModel.cs`;
- Refactors `PriceIsFavorable` methods in `StandardDeviationExecutionModel` and `VolumeWeightedAveragePriceExecutionModel` C# models;
- Adds python version of C# execution models
The cleanest way to get a python type name, when we know it is an instance of a class, is getting the value of the `__class__.__name__` attribute.
- Changes `CommonAlphaModelTests.ModelNameTest`:
Since it requires some string manipulation to have the exact model name for C# and Python, we don't define `Name` in the python models and accept the default value from `AlphaModelPythonWrapper.Name`.
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.
The composite model combines multiple alpha models into a singular model and
properly sets each insight's SourceModel property to the name of the model that
generated the insight
Alpha models can choose to implement the Name property, if not, the system
will use the model's type name as the Insight.SourceModel.
Existing tests were updated to also assert expected model names
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 PyObject parameter is converted into selector function of `Func<T1,T2>` type so that the model can user universe selector methods defined in python algorithms.
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.
AlexCatarino