* Changed argument exceptions so that they used the nameof() operator for parameter names
* Update IQSocket.cs
---------
Co-authored-by: John Doe <john@doe>
Co-authored-by: Martin-Molinero <martin@quantconnect.com>
Regression Tests / build (push) Has been cancelled
Python Virtual Environments / build (push) Has been cancelled
Benchmarks / build (push) Has been cancelled
Build & Test Lean / build (push) Has been cancelled
Research Regression Tests / build (push) Has been cancelled
* Refactor alpha statistics
- Refactor alpha statistics, cleaning up and simplifying no longer required calculations and scoring
- Adding new InsightEvaluator abstraction, adding C# & PY regression
algorithms
* Optimization backtest result json converter update
* Address reviews
- Remove IAlphaHandler, move insight storage responsability to IResultHandler
and centralizing insight collection on the QCAlgorithm.Insights to be
reused by the framework models
- Fix portfolio turnover single day backtests and duplicate time
sampling handling. Updating regression algorithms
* Add InsightCollection tests and minor fixes
* Adding more & improved tests
Regression Tests / build (push) Has been cancelled
Python Virtual Environments / build (push) Has been cancelled
Benchmarks / build (push) Has been cancelled
Build & Test Lean / build (push) Has been cancelled
Research Regression Tests / build (push) Has been cancelled
The calculations of `CloseTimeUtc` are correct and consistent: if the exchange is closed when the insight expires, `CloseTimeUtc` is the next open.
However, the definition of the `Period` was not consistent. Normally, it is defined by the different between `CloseTimeUtc` and `GeneratedTimeUtc`, but when we create an Insight with the Resolution and bar count overload, the period was defined by them:
```csharp
insight.Period = Resolution.ToTimeSpan().Multiply(BarCount);
```
which is incorrect, since it doesn't take the days the exchange is closed into account. The `ComputePeriod` method enforced consistency between the Resolution and bar Count overload and the `DateTime` overload, so the period for this overload was also incorrect.
* Add notification targets and events to live packet
- Add notification targets and events to live packet. Adding unit tests
* Add project name to job packet
* Add ShortToString and WebNotification Header
- Adding ShortToString implemnetation of OrderEvent and Insight
- Add Web notification headers
* Add more unit tests
* Revert json lower case fields
Implement a new overload to `Insight` constructor that accepts a `Func<DateTime, DateTime>` that is used to compute the `CloseTimeUtc` and `Period` after the `Insight` object is emitted (`SetPeriodAndCloseTime` method).
Adds the static Expiry class with functions that can be used to compute a future date/time (expiry) given a date/time.
Closes#3038
- Classic Algorithms will emight insights based on order fills.
- To be able to update generated insights closed time, we will not
clone emitted insights.
- `InsightAnalysisContext` will update `AnalysisEndTimeUtc` when the
Insight period is closed and the period is `EndOfTimeTimeSpan`
- Adding new regression algorithm asserting on the new emitted insights
- Adding unit tests
- `LiveTradingResultHandler` will store `AlphaRunTimeStatistics`
- Making `DefaultAlphaHandler.ProcessAsynchronousEvents` virtual to
facilitate cloud changes
Fixes a bug where we were using the security's data resolution to compute
the insight's close time. This led a case such as insight.Period == 20days
to step 20days worth of tradable minutes (assuming minute data resolution),
yielding a close time that was very far in the future.
We also add different means of specifying an insight's period/close time:
1. Specify insight period as a TimeSpan and we compute close time
2. Specify insight period and a resolution and bar count and we compute close time
3. Specify insight close time local directly and we compute the insight period
The key here is maintaining consistency between the three different approaches
which is heavily validated with the corresponding unit tests.
Edits also made to trust the insight's close time as the analysis end time in
the case where the analysis period == insight period (extra analysis period = 0).
Given the current setup (extra analysis period == 0), this guarantees that close
and analysis end times are equivalent.
Regression statistics were updated and expectedly we get many more insights that
have completed analysis, and as such, average scores have also changed.
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.
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`.
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.
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.
Jhonathan Abreu