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
When focusing on generating alpha signals we don't need t both with execution or
portfolio construction models. Instead we can judge how well we do based on our
generated alphas. By not submitting orders, backtests and live performance is
greatly improved.
In this update, methods overloads with decimal parameters accept python float.
- Fixes FractionalQuantityRegressionAlgorithm:
With the pythonnet update we can pass a python float where a decimal is required.
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 PR is an attempt to reduce contention in concurrent dictionaries, replacing method calls using full locks with lock-free equivalents:
- dictionary.Count -> dictionary.Skip(0).Count()
- dictionary.Keys -> dictionary.Select(x => x.Key)
- dictionary.Values -> dictionary.Select(x => x.Value)
The most frequent usages of these methods are: CashBook, SecurityManager, UniverseManager and indirectly, SecurityPortfolioManager.
The reasons for this update are explained very clearly in this article:
https://arbel.net/2013/02/03/best-practices-for-using-concurrentdictionary/
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.
Internally we're materializing the symbols enumerable from the signal model and then
passing that into the portoflio construction model. So we already have the list. In
addition, a common task is to check the count of the signals for use in further math,
such as determining weighting percentages, ect...
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.
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.
It's not unreasonable to think users will provide their own ISignal implementation
and we'll want them all behaving by the same serialization rules to make consumption
much easier.
Since these are really just data structures they belon in the common library. Also,
it stands to reason that we'll want to reuse them in other components, such as the
result handler.
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.