Hi,

Yes, we currently are sending events with just the price at the close of the (day or minute) bar. The idea is to maintain a consistent interface between bar data for historical testing, and event data for live trading. Do you think this is a design error we should fix?

thanks,
fawce

Hello John,

Really depends on who you want as traders ...

Some combination of High, Low, Open, Close, Volume are the basics used by most technical indicators. So, if you want to support technical trading, then you need to provide that data. Very, very broadly: longer time horizon stat arb-ish strategies tend to use only Close (typically called Last in that context); shorter time frame quant strategies will sometimes build signals from h/l/o/c.

If you describe a bit about why there's a conflict between bar and event data in your system, I might have some suggestions. It doesn't immediately make sense to me that there would be a conflict between these two types of data.

Also, I don't understand what you're calling an 'event', there are lots of different events in a market data feed. The raw market events are mainly quotes and trades.

Obviously it's best if you provide the exact same data elements historically and live. It's providing good historical data that's the problem. For example, historical bid/ask size can be difficult to find. So when writing a strategy you have to do the best you can with the data you've got, make conservative assumptions, and still you might end up doing some of your testing in paper trading or (if it can be done prudently) while scaling into live trading.

Regards,
David K.

Seems like on an hourly/daily basis (or any time scale greater than a minute), the high/low/open/close could be calculated from the minutely data, right?

Regarding the definition of an "event" see this discussion. As I understand, the "event" database is a list of minute-by-minute security prices, somehow derived from real-world data. If no price was available for a given minute, then the minute is skipped and there will be no triggering "event" when the backtest is run.

Hello Grant,

Not really. You don't know what happened in that minute, so you can only approximate the h/l/o/c. Normally if you want to roll up shorter time bars into longer ones you take the max(High(t1:t2)) and min(Low(t1:t2)) to get the longer period high and low.

However the approximation may be perfectly fine. The largest driver of strategy design choices w.r.t data is time horizon. A strategy that trades daily is very unlikely to care about the small difference between the real High and the high created by max(Close(:)) for that day.

-David K.

John,

Based on reading the link in Grant's reply, I'd say that you are make a design error. It appears you are pretty much assuming market orders. Limit orders are an important order type. To make a decent backtester with limit orders you need the H/L for the minute.

I like a lot of what you've done as an integrated environment. However it seems like you're focused on a particular trading style. Something like a stat arb system that trades no more then about once a half hour.

-David K.

PS. Your slippage model [to my view of things] is really mixing apples and oranges. The Volume Share slippage is approximating an execution algorithm. The Spread based slippage seems poorly named and doesn't really do anything; I could just subtract out the fixed round-trip cost at the end of the simulation ... I see ... you want to plot running p&l so you need to subtract out the cost at each trade. Finally slippage should be a function provided by the user; if you're being Quant-ish about things, then your cost model is important, you've thought about it, and you want to provide your own.

Hi David,

According to the help page, a "minute bar is a summary of the trading activity for a security for a one-minute period, and gives you the opening price, closing price, and trading volume during that minute." However, under the "Event Properties" section, I do not see a description of how to access the open/close prices (only "price" is listed). I'll submit another post to ask for clarification.

Regarding limit orders, it seems like the Quantopian backtester should be able to handle them, with the appropriate logic in the algorithm (e.g. only buy below a specified price and only sell above a specified price).

Hello David,

It turns out that Quantopian has open/high/low/close prices and total volume for each minute and is working to make the data available for backtests (see John Fawcett's comments here).

Hello Grant,

It would be surprising if their data didn't have o/c/h/l data. I also noticed the lack of total volume for the minute; the volume of the last trade is sort-of interesting, but total volume is generally more useful. Although usually what I see is cumulative volume.

I discovered the Quantopian Manifesto and skimmed it. I can see from that whey they wouldn't bother with h/l data. It's much more Quant-ish to think of sampling the market across a lot of symbols, compared to using high/low information which is noisy and not as "reliable".

Hopefully the Quantopian people will answer this thread or include in an email update when they fix their bugs with O/C/H/L data.

We actually have the open/close/high/low prices already loaded into our database. We have to do some work to expose the data to the UI. That shouldn't take too long; I'm hopeful that we can get it done this month. I'll post when we do it.

The volume, just to be clear, is the total volume traded in that given minute.

Thanks for the update. Up above in the thread John wrote you wanted to maintain a consistent interface between backtest & live. I hope it's clear that in live trading you can send bar data just as easily as 1-minute 'event' data.

Yes, that makes sense.

Sorry if this has been covered already, but is it possible to use a moving average (simple or otherwise) based on highs/lows/open prices? Or would we have to do it ourselves? If so, would this approach work (or is it horrendously flawed?):

def movingaverage(interval, window_size):  
      window= np.ones(int(window_size))/float(window_size)  
      return np.convolve(interval, window, 'same')  
price_high = data[context.aapl].high  
price_low = data[context.aapl].low  
MA_high = movingaverage(price_high,10)  
MA_low = movingaverage(price_low,10)

your alternatives appreciated :)

Hello Billy,

You could use TA-Lib and have a library of indicators from which to choose.

P.

Thanks a million Pete!