Build & Test Lean / build (push) Has been cancelled
Regression Tests / build (push) Has been cancelled
Report Generator Tests / build (push) Has been cancelled
Research Regression Tests / build (push) Has been cancelled
Python Virtual Environments / build (push) Has been cancelled
* Minor api improvements
- Adding Universe.Selected to hold the current set of selected symbols.
Adding regression tests
- Adjusting TimeRules and DateRules to fallback to the MHDB if the
security hasn't been added. Updating existing regression tests
* Expand regression test assertion
- Adds PyObject overload to `ScheduleManager.TrainingNow` and `ScheduleManager.Training`
- Adds `QCAlgorithm.Train` helper method
- Adds Python algorithm showing how to use the helper method.
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
These are simple, easy to use convenience properties for creating short-term
scheduled events and produces a cleaner, easier reading syntax than using the
other various methods to produce the same result, for example:
Schedule.On(DateRules.Tomorrow, TimeRules.Noon, MyScheduledEventMethod);
Also fixes typo in FuncDateRule constructor parameter.
Adding an overload to `ScheduleManager.On` method that accepts a `PyObject` parameter enables python algorithm to pass a method as parameter directly.
- Fixes `ScheduleEventsAlgorithm` to show the new feature in action.
Algorithms can now use syntax like the following to define events:
Schedule.Event(name).{DateRuleMethod}.{TimeRuleMethod}.Run( lambda )
For example: Schedule.Event(tues).Every(DayOfWeek.Tuesday).AfterMarketOpen(SPY, 20).Run(MyTuesdayHandler);
Adds the ScheduleManager which allows an algorithm to add/remove scheduled events
Check out the ScheduledEventsAlgorithm for syntax
ScheduledEvents are at their core an IEnumerator<DateTime> that defines the event times coupled with a callback
IDateRule defines dates for events
ITimeRule defines time(s) on a given date for events
Jhonathan Abreu