* Add offset capabilities and related tests
* Add tests for Weekend Offsets on Symbol DateRules
* Unify Iterator Behavior
* Refactor and consolidate functions to reduce duplicate code
* Positive offset values only
* Address review
* Expand Month tests to include Forex and Crypto cases
* Ensure order of days in schedule
* Refactor and unify behavior
* More edge cases and tuning
* Address review + more tests
- `ITimeRules` are expected to yield time date in UTC, fixing `Noon`,
`Midnight` and `Every`
- `ScheduledUniverseSelectionModel` will use UTC time zone by default
since that is the default expected time zone `ITimeRule` provides
- Adding regression test
- 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.
When adding a new ScheduledEvent with exactly one event time set
to the algorithm's current time, the SkipEventsUntil function would
skip the only event. It appears that this bug was 'fixed' via commit:
33a4db4559
This 'fix' is more of a bandaid and I'm forgoing undoing the bandaid
applied in ScheduleManager and ScheduledEventBuilder where we start
calculating the event schedule a full day before the algorithm's
current time in an effort to reduce additional potential risks from
creeping into this PR focused on adding support for long-running
training functions.
The `NullReferenceException` type is intended to only be thrown by the CLR.
In most cases, it should be converted to an `ArgumentException` or an
`InvalidOperationException`, depending on if the null value is a parameter
to the current method or not.
The `Exception` type should never really be thrown as it doesn't provide any
additional information or hints as to the issue. It also forces users that
would like to handle expected exceptions to catch all exceptions. These are
converted to an exception type that more accurately describes the reason for
raising the exception: `KeyNotFoundException`, `InvalidOperationException`
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.
Without the inner exception, information on the user exception is lost. In python algorithm, the stack trace is completely lost.
Removes ScheduledEventExceptionMessage property as it is redundant to Message property inherited from parent class.
- MonthEnd(): fires on the last day of each month
- MonthEnd(Symbol): fires on the last tradeable date for the specified symbol of each month
- WeekStart(): fires on Monday each week
- WeekStart(Symbol): fires on the first tradeable date for the specified symbol of each week
- WeekEnd(): fires on Friday each week
- WeekEnd(Symbol): fire on the last tradeable date for the specified symbol of each week
Catching the exception in BacktestingRealTimeHandler prevents unhandled errors in backtesting and provides more specific logging to make debugging easier for users
These changes fix a bug so that when an exception is thrown with the LiveTradingResultHandler, the error is handled and the next scheduled event can happen as scheduled.
This includes updating all usages of symbol as a security identifier to use the new type.
The type includes a unique field, SID, as well as the current ticker's value. This allows
for consistent addressability while also allowing the ticker to evolve over time with the
mapping changes.
Effort was made to maintain compile and runtime backwards compatibility.
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
Colton Sellers