- Adding `FreePortfolioValue` to be set after algorithm initialize based
on the `TotalPortfolioValue` and the `FreePortfolioValuePercentage`
- Updating regression tests
- Adding new regression test
- Adding check for minimum order value at `BuyingPowerModel`
- Set `CanRunLocally => false` for training regression algorithms
- Reverting sorting changes at `BacktestingRealTimeHandler` due to
performance degradation of current scheduled event benchmark algorithm
- Add `ProbabilisticSharpeRatio` to `PortfolioStatistics`
- `Probabilistic Sharpe Ratio` will be added to the `RunTimeStatistics`
sent by the `ResultHandlers`
- Making `TradeBuilder.ClosedTrades` thread safe since its accessed by
the `ResultHandlers`
- Removing `:` from live runtime statistics
- Adding unit tests
In order to continue to provide debugging support in the QC cloud, the
scheduled events were moved from inside of a task to the algorithm's
main execution thread. This necesitated a different methodology for
managing timeouts. Instead of raising an exception when attempting to
request additional time when none is remaining, we're now simply allowing
the isolator's limit to be reached by virtue of not incrementing the
additional minutes in the time manager. This uncovered a bug in LEAN
engine where if the isolator terminates an algorithm, then the status
of the algorithm (on the algorithm manager instance) isn't properly
updated to indicate RuntimeError. This is in direct conflict with the
status update that is provided to the api, which is RuntimeError, so
this change remedies that issue as well. One of the regression algorithms
depends on this status value being properly flipped to RuntimeError in
the event that the isolator limit is reached.
See #3319
We restrict each algorithm time loop to a pre-determined amount of time.
Exceeding this limit will cause the algorithm to immediately terminate.
This quickly becomes an issue when considering users running trainable
models that have a long initialization period that exceeds the time loop
maximum.
This change provides a mechanism through which a long-running scheduled
event is permitted to keep running and is permitted to avoid the time loop
permitted by requesting additional time. Requests for additional time are
limited according to a leaky bucket implementation whose parameters are
set via the job's controls structure. The fundamental time unit for the
algorithm is a single minute.
Here's how it works. If a scheduled event takes longer than one full wall
clock second then a request is made to the leaky bucket for one more minute.
If the scheduled event continues to take more time, it will continue to
request additional minutes. Each requested minute will prevent the algorithm's
time loop check from terminating the algorithm. When the bucket is empty and
no more minutes are available to be requested, a TimeoutException is thrown
causing a cascade that ends in the algorithm's termination and status being
flipped to RuntimeError.
Additionally, this applies equally to ALL scheduled events. While some helpers
were added with the naming of Train and TrainNow to the ScheduleManager, these
methods don't do anything special and the infrastructure doesn't otherwise
flag them as different, so this feature becomes part of the core Scheduled
Event feature set.
Further, the live scheduled events were not touched and are still pending
further discussion regarding the value added by enforcing a time restriction
when simulation time and wall clock time are equivalent.
Fixes#3319
- Adding new `ConfidenceWeightedPortfolioConstructionModel` (C# / Py) that will
generate percent `Targets` based on the latest active `Insight` `Confidence` per
`Symbol`.
- Will ignore `Insights` that have no `Confidence`.(unit tested)
- If the sum of all the last active `Insight` per `Symbol` is bigger than 1, it
will factor down each target percent holdings proportionally so the sum is 1. (unit tested)
- Adding unit tests
- Adding a new regression test framework algorithm (C#/Py)
-**Note**: `ConfidenceWeightedPortfolioConstructionModel` inherits from the `InsightWeightingPortfolioConstructionModel`. Protect method `GetValue` was implemented in `IWPCM` to enable the choice of `Insight` member.
* Adds and removes various fields from enums to represent data accurately
* Renames various variables
* Changes algorithms to work with new changes
* SmartInsider transaction/intention docs updated
* Added new enum values to represent pieces of data
* Updates Smart Insider demo algorithm end date for presentation
purposes of the equity curve
* Adds liquidation logic to SEC and Smart Insider demo algorithms
- Add `TiingoNews.HistoricalCrawlOffset`, timespan to add for
backtesting
- Rename: remove `Data` from `TiingoNewsData` and rename `TiingoDailyData` to `TiingoPrice`
Adds IRegisteredSecurityDataTypesProvider to track all the data types
registered in the algorithm. Using this data, we can detect if it's
possible that we'll eventually have a property of a certain type name.
For example, consider I wish to use security.Data.TradeBar but we haven't
received any trade bars yet. Before this change a KeyNotFoundException
would be raised, but since we can determine that we expect to have trade
bars, we can detect this and return an empty list when we haven't received
any data yet. This also removes the need to constantly do a HasData<T>()
check before accessing the dynamic members.
Closes#3620
Provides dynamic access to cached security data keyed by the type's name.
For example, `security.Data.GetAll<Tick>()` would yield a list of ticks.
Likewise, using the dynamic accessors, `((dynamic)security.Data).Tick`
would return the same list. In C# you'll need to cast security.Data to
a dynamic. In python, all C# objects are viewed as dynamic, so python can
simply access `security.Data.Tick` directly.
See #3620
Martin Molinero