Can someone help me understand these results please?

Sorry if this seems daft, but it's my first go at using QuantConnect.

When I run the attached strategy, the log looks like this:

2014-01-01 00:00:00 Launching analysis for 2ef32a341854ccc1f2531613eee2ab4c with LEAN Engine v2.1.4.3

2014-01-02 10:04:00 Renko 2014-01-02T10:01:00.0000000 - OHLC[177.40, 177.40, 177.35, 177.35] - SMA - 177.46896231875996450295379663

2014-01-02 10:05:00 Renko 2014-01-02T10:03:00.0000000 - OHLC[177.35, 177.35, 177.30, 177.30] - SMA - 177.44482484465139814538896854

2014-01-02 10:06:00 Renko 2014-01-02T10:04:00.0000000 - OHLC[177.30, 177.30, 177.25, 177.25] - SMA - 177.41699272398691269604768732

2014-01-02 10:07:00 Renko 2014-01-02T10:05:00.0000000 - OHLC[177.25, 177.25, 177.20, 177.20] - SMA - 177.38599376341735373946944627

2014-01-02 10:10:00 Renko 2014-01-02T10:06:00.0000000 - OHLC[177.20, 177.25, 177.194293227, 177.25] - SMA - 177.36656608292916034811666823

2014-01-02 10:11:00 Renko 2014-01-02T10:09:00.0000000 - OHLC[177.25, 177.30, 177.25, 177.30] - SMA - 177.35705664251070886981428706

2014-01-02 10:13:00 Renko 2014-01-02T10:10:00.0000000 - OHLC[177.30, 177.35, 177.30, 177.35] - SMA - 177.35604855072346474555510319

2014-01-02 10:14:00 Renko 2014-01-02T10:12:00.0000000 - OHLC[177.35, 177.40, 177.35, 177.40] - SMA - 177.36232732919154121047580273

2014-01-02 10:14:00 BUY >> 177.426260883

2014-01-02 10:22:00 Renko 2014-01-02T10:13:00.0000000 - OHLC[177.40, 177.40, 177.35, 177.35] - SMA - 177.36056628216417818040783091

2014-01-02 10:22:00 SELL >> 177.339273012

2014-01-02 10:23:00 Renko 2014-01-02T10:21:00.0000000 - OHLC[177.35, 177.35, 177.30, 177.30] - SMA - 177.35191395614072415463528364

2014-01-02 10:26:00 Renko 2014-01-02T10:22:00.0000000 - OHLC[177.30, 177.30, 177.25, 177.25] - SMA - 177.33735481954919213254452884

2014-01-02 10:28:00 Renko 2014-01-02T10:25:00.0000000 - OHLC[177.25, 177.30, 177.25, 177.30] - SMA - 177.33201841675645039932388187

2014-01-02 10:32:00 Renko 2014-01-02T10:27:00.0000000 - OHLC[177.30, 177.310277055, 177.25, 177.25] - SMA - 177.32030150007695748513475589

2014-01-02 10:42:00 Renko 2014-01-02T10:31:00.0000000 - OHLC[177.25, 177.30, 177.213623865, 177.30] - SMA - 177.31740128578024927297264791

2014-01-02 10:43:00 Renko 2014-01-02T10:41:00.0000000 - OHLC[177.30, 177.35, 177.30, 177.35] - SMA - 177.32205824495449937683369821

As you can see from the Buy, the buy price is 177.42, but the following Renko Bar has a high of 177.40, so I'm getting filled at what feels like an inconsistent price. But looking at the time of the log versus the time of the Renko bars, they look inconsistent too. I can't tell whether it's a problem with my code, the Renko consolidator, or the Purchasing logic.

Any help understanding this would be greatly appreciated.

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.

OK, got a little bit further tracking this. It would seem that the event isn't fired for some minutes after the bar is created, and that seems very wrong to me. I added the following log message to the algo:

        	Log(String.Format("Difference between time and end time of bar: {0} - {1} : {2}", data.Time - data.EndTime, data.EndTime, Time));

and ended up with the following output:

2014-11-03 09:38:00 Difference between time and end time of bar: 00:00:00 - 11/03/2014 09:30:00 : 11/03/2014 09:38:00
2014-11-03 09:42:00 Difference between time and end time of bar: 00:00:00 - 11/03/2014 09:37:00 : 11/03/2014 09:42:00
2014-11-03 09:53:00 Difference between time and end time of bar: 00:00:00 - 11/03/2014 09:41:00 : 11/03/2014 09:53:00

Obviously the bar times match up, as do the time of the log, and the current contextual time of the algo. but the difference between the contextual time and the end time of the bar (in the 3 log messages above) ranges from 5 minutes to 12 minutes. I'd understand if that was seconds, but not minutes. I think that just might be a bug in QC code somewhere. I'll log it as such.

Paul Saunders INVESTOR

November 2015

OH, and yes, I do realise the logic for not trading after 1pm is incorrect. It looks as if the Renko event isn't firing for several minutes.

Upvote

Michael Handschuh INVESTOR

Hey Paul, Renko bars are timeless bars, so the times shouldn't be consistent. Renko bars are defined by movements in values, not by movements in time (like trade bars or other consolidated bars). Maybe I'm misunderstanding your question. Fills are performed based on the closing price during the interval at which you made the trade. So for example, if you make a trade at the opening bell using minute data, we'll using the closing price of the minute bar (that is, the price as of the last moment before 9:31am)

Hi Michael, Thanks, help appreciated. I am aware of the timelessness or timeliness(depending on your point of view) of the Renko bars. What concerns me is that as I get a bar; say one that finishes @ 09:30 (data.EndTime), I'm not receiving it in the event handler until way past 09:30, in the vicinity of 09:35 to 09:42. In my mind, that should be received within a few millisecond, tho I'd be happy to wait a few seconds for it. As a result, I'm placing trades @ prices that have already moved way past what I would have expected. If this were a standard minute bar, it would be the same as receiving the 09:30 bar at 09:38'ish, and the order placement filling at the 9:38'ish bar close. I doubt anyone could code a decent strategy with that kind of lag. I wasn't aware of the price filling, so thanks for that. However, it would not seem that this is true of consolidated feeds like the Renko. If that were true, the "BUY" from the original log would read 177.35 (I think that's correct). Replaying time at an accelerated tempo can be a tricky business, and I suspect there is something just a bit off in the code that does the time scheduling for the backtesting. I doubt this strategy would exhibit the same problems in a "Live" context. I have had a little snoop around the code, but haven't spotted anything yet (I'm time limited unfortunately), and will continue to look as I have time. Still, I am a noob at this, and my thinking may be well off, so please feel free to correct my ignorance.

Sorry, just in case it's not obvious, the RenkoBar has a StartTime and EndTime, indicating when it started and finished the sampling for the bar (at least that is my interpretation).

Upon a second look, it looks like you're logging the start time of the bar instead of the end time of the bar, so the delta you're seeing is actually the time length of the bar.

Log(String.Format("Renko {0} - OHLC[{1}, {2}, {3}, {4}] - SMA - {5}", data.Time.ToString("o"), data.Open, data.High, data.Low, data.Close, _ema.Value));

All consolidators work on an event based system, so they don't actually 'know' what time it is, they just fire events when they decide the data has finished consolidation. For the 'current' time of the algorithm, use the IAlgorithm.Time property

You're absolutely right, I was logging that. In my subsequent post, I added another log, which includes the data.EndTime, and the IAlgorithm.Time Property. The disparity is there still. For clarity, I've re-attached the project, with all my intermediate changes.

Jared Broad INVESTOR

QuantConnect | November 2015

Hey Paul! Thanks it looks like you've discovered a bug in the RenkoBar class. We dug into it and the bars are emitted perfectly (on time) but the "EndTime" property isn't being set, so its defaulting to the start time. You can see the real Renko end time with the "End" property. We've pushed a fix to github and it will be live in a few days =) In the fix the "EndTime" property will be the same as a the "End".

Fixed in this commit. Thanks for finding/reporting this bug!!

Thanks guys, glad to be of some help. And that's a prompt fix! FYI, running the test again using data.End instead, shows a 1 minute difference between it and IAlgorithm.Time. Not sure if that'll have an impact. That takes me back to my original observation tho. The "BUY" is at a price higher than the high of the current, previous and next RenkoBars. Any ideas why that might be?

FYI: I managed to figure out what was going on. The "Price" for the Renko bar is the close price of the underlying TradeBar, but the close is obviously an increment of the Renko bar size. Dropping the time frame of the consolidator created a close value much more in line with the Price....

Platform

Radically Open-Source Algorithmic Trading Engine

Join Our Discord Channel

Quarterly Open-Source Trading Competition

Draft Discussions

Bookmarked Discussions

SEARCH DISCUSSIONS

361,600 Quants.

VOTE FOR UPCOMING FEATURES

JOIN OUR Community MAILING LIST

IN THIS RESEARCH

PARTICIPANTS

Actions

Join QuantConnect for Free