Hi Grant,

You are correct in that the first trade must be encountered before a stock can be added to data. This means that a trade for this stock cannot be placed any sooner than 1 minute after this first trade.

There is no current rationale as to why this is the case. It was initially implemented this way due to technical challenges (this was before history() was around), and hasn't been improved since. We recognize that this isn't ideal and it's something that's on our list of things to improve.

I hope this answers your question.

+1

It might be interesting to let us know a couple of days before this change, a bunch of people run some of their algos and store results in detail and then again after the change to see any difference. Especially for live/real then, a few might want to make an adjustment if differences are noteworthy.

By the way I think currently in the case of a scheduled market_open, if a sid doesn't trade until the 300th minute, that is considered its open, the order would be placed then (it isn't skipped just because it didn't trade on minute 1, for example that month if monthly). Pls correct me if I'm wrong.
While the code-surgeon-developers have the patient opened up, I wonder if this might not also be a good time to have backtest open orders canceled at the end of the day too, to match live. For testing, maybe track_orders() can help.

Thanks Jamie,

Is it a particularly sticky problem? Both history() and update_universe() have been around awhile, so perhaps you could elaborate on the difficultly in implementing the change?

Grant

Grant,

Our engineers are always working on improving the quality of the platform whether it be by adding new features, or improving existing ones. This particular issue hasn’t been at the top of the priority list but a solution for it is in the works. There’s no timeline on when it will be fixed but this issue will be addressed.

As I understand, a stock must be in data before its price can be found. When you specify the number of shares, directly by using order or indirectly by order_target, orders should go through. (Their execution will then wait in backtesting or paper trading until one or more trades have occurred on the exchange, because Quantopian needs a price from the market to feed to the slippage model, but that's another issue.) When the number of shares must be calculated using the price, as in all the order_*value and order_*percent functions, and stock is not in data, Quantopian throws an error ("Something went wrong").

I suspect Quantopian uses data[stock].price to find the latest price in order_*value and order_*percent, without checking if stock in data, and without falling back on history otherwise. It also does not care to recognize what "went wrong", and to report it to the user in an informative way. True?