Quantopian's community platform is shutting down. Please read this post for more information and download your code.
Back to Community
Introducing time-delay in a single "handle_data" run
Brk Yng
posted Aug 29, 2014

Hi,

I'd like to be able to have the option to cancel all open orders, and then place new ones in a single handle_data call. In other words, I do not want to cancel trades first, and then wait for handle_data to be called again due to a new tick coming through during live trading.

To do this, I would first want to check that the orders are properly cancelled, but to do that I have to wait a bit (say, 1 second) before this is possible.

when I apply a time.sleep(1) within handle_data, I get errors.. I imagine this is likely because the library do not know how to handle such cases?

If it does know how to handle it, would you please provide an example of how to introduce a time delay? How should we expect the back-testing behaviour to be in such cases of time delay introduction?

Many thanks,

3 responses
Alisa Deychman
Sep 5, 2014

Hi Burak,

The current mechanism of events in handle_data is linear - an order gets submitted in one bar and then filled in the subsequent bars according to the slippage model. We don't yet have the ability to add concurrent requests in a single call of handle_data; to simultaneously cancel an order and then submit a new order. The nuance here is how to control scenarios in live trading because we cannot control the actions of the broker. The broker may receive the first order and fill it, then receive the second order and fill it, so when the cancel request arrives, there is no open order to cancel. I think it's a great feature and one that we'd like to build towards.

Cheers,
Alisa

Disclaimer

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 Quantopian. In addition, the material offers no opinion with respect to the suitability of any security or specific investment. No information contained herein should be regarded as a suggestion to engage in or refrain from any investment-related course of action as none of Quantopian nor any of its affiliates is undertaking to provide investment advice, act as an adviser to any plan or entity subject to the Employee Retirement Income Security Act of 1974, as amended, individual retirement account or individual retirement annuity, or give advice in a fiduciary capacity with respect to the materials presented herein. If you are an individual retirement or other investor, contact your financial advisor or other fiduciary unrelated to Quantopian about whether any given investment idea, strategy, product or service described herein may be appropriate for your circumstances. All investments involve risk, including loss of principal. Quantopian 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.

Grant Kiehne
Sep 6, 2014

Hello Alisa,

My understanding is that communication to IB from the algorithm is asynchronous, so that order cancellations and orders are sent immediately, as they are encountered in the code. However, communication from IB to the algorithm occurs at a minutely frequency, just prior to the call to handle_data. So, it would seem possible to send a cancellation request followed by an order, all within a single call to handle data. The problem is that confirmation of the cancellation will not be available until the next call to handle_data, correct?

Are you actually thinking of trying to build in asynchronous two-way communication with the broker, so that information could flow back from the broker within a call to handle_data, accessible to the algorithm?

Grant

Alisa Deychman
Sep 9, 2014

The communication from the algorithm to IB is indeed asynchronous, but if an algorithm places both a cancel and an order call in the same run of handle_data, we cannot guarantee that IB will receive or act upon them in that sequence.

We'd like to make information from the broker available in the algorithm and we're marching closer to this goal!

About Quantopian
Careers
Community
Events
Documentation
Academia
Lectures
Status
Facebook
Twitter
LinkedIn
YouTube
Terms of Use
Privacy Policy

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 Quantopian.

In addition, the material offers no opinion with respect to the suitability of any security or specific investment. No information contained herein should be regarded as a suggestion to engage in or refrain from any investment-related course of action as none of Quantopian nor any of its affiliates is undertaking to provide investment advice, act as an adviser to any plan or entity subject to the Employee Retirement Income Security Act of 1974, as amended, individual retirement account or individual retirement annuity, or give advice in a fiduciary capacity with respect to the materials presented herein. If you are an individual retirement or other investor, contact your financial advisor or other fiduciary unrelated to Quantopian about whether any given investment idea, strategy, product or service described herein may be appropriate for your circumstances. All investments involve risk, including loss of principal. Quantopian 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.