Share New Research 
I'm trying to schedule "happen once" events, is Schedule.On appropriate for that? The reason I'm wondering is because it seems my backtest gets increasingly slower the longer it runs, I'm afraid events aren't removed and keep being tested (I've not been able to find in Lean code how they would be removed).
Background: I'm doing something like this to simulate order delay (side note: it would be nice with a different overload that simply took a TimeSpan assumed relative to current QCAlgorithm.Time):
private void BeginSubmitMarketOrder()
{
var delay = _delayGeneratorInSeconds();
if (Algorithm.LiveMode || delay <= 0)
{
SubmitMarketOrder(_orderParams);
}
else
{
//TODO: would prefer something that doesn't go bananas when at midnight...
var now = Algorithm.Time;
_inSimulatedSubmissionDelay = true;
Algorithm.Schedule.On(
Algorithm.Schedule.DateRules.On(now.Year, now.Month, now.Day),
Algorithm.Schedule.TimeRules.At(now.TimeOfDay + TimeSpan.FromSeconds(delay)),
() => SubmitMarketOrder(_orderParams.Clone())
);
}
}
Alexandre Catarino
Schedule events should go into Initialize. Otherwise it will be triggered constantly.
It looks like you want to send an market order with a delay and the order trigger can happen in any time. Schedule events are not appropriate for that.
One way to accomplish what you want (you probably have thought of that already) is to record the time of the trade signal, add the delay and then compare it againt the Algorithm.Time.
Alexandre Catarino
Let me explain what I meant for "Otherwise it will be triggered constantly". In fact, the event will not be triggered constantly, but we are adding several schedule events to the schedule manager.
Petter Hansson
"One way to accomplish what you want (you probably have thought of that already) is to record the time of the trade signal, add the delay and then compare it againt the Algorithm.Time."
Of course that is the most obvious way of doing it, however, it means that order submission is delayed until the point you can actually call Algorithm.Time. In a tick algo, this means next trade/quote, in bar algo it means call time will be quantized by 1 s, or 1 min, etc. In the tick case in backtests, I'm not sure if it actually makes much of a difference (other than the tick triggering the order probably not being considered towards filling the order). For bar algos it doesn't work as desirable though. When it comes to live algos, this approach is unsatisfactory (but I don't need it for what I'm doing).
To illustrate my deam API for this, to work both on backtests and live algo:
Algorithm.Schedule.Once(DateTime when, Action callback); //callback triggered as soon as when has happened
Algorithm.Schedule.OnceFromNow(TimeSpan delay, Action callback); //callback triggered after at least delay amount of time has passed since call
(There may be logical reasons not to put this in ScheduleManager, but I'm just thinking from a black box perspective now and it's a minor detail anyway.)
Petter Hansson
The material on this website is provided for informational purposes only and does not constitute an offer to sell, a solicitation to buy, or a recommendation or endorsement for any security or strategy, nor does it constitute an offer to provide investment advisory services by QuantConnect. In addition, the material offers no opinion with respect to the suitability of any security or specific investment. QuantConnect makes no guarantees as to the accuracy or completeness of the views expressed in the website. The views are subject to change, and may have become unreliable for various reasons, including changes in market conditions or economic circumstances. All investments involve risk, including loss of principal. You should consult with an investment professional before making any investment decisions.
To unlock posting to the community forums please complete at least 30% of Boot Camp.
You can continue your Boot Camp training progress from the terminal. We hope to see you in the community soon!