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.
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.
This forces the quantity computation to be performed from the portfolio construction model.
As a result of this change, we've removed the Percent and Quantity implementations and
replaced them with just a PortfolioTarget implementation that is equivalent to the previous
Quantity implementation. Users can still use the static Percent method to generate the
correct quantities for a target for the common case of a percent weighted portfolio.
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?)
Michael Handschuh