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

Jonathan Evans INVESTOR

December 2015

So, let me make sure I understand this: (1) The universe is a set of symbols, defined by a user-supplied filter function. (2) Every (UniverseSettings.Resolution) time span, the universe will be updated by calling the filter function. (3) If and only if the set of symbols changes, OnSecuritiesChanged is called and given a SecuritiesChanges object. Is that an accurate summation? Any potential gotchas or limitations we should be aware of?

1. Absolutely spot on! A little more specific though, in general, a universe takes in some data (in this case CoarseFundamental) and returns a filtered set of symbols. In another forum post I demonstrated how you can use your own custom data sources for universe selection data! There also exist overloads that only accept a DateTime argument and return a set of symbols, useful for hitting an external API that doesn't lend itself to our custom data system. EDIT: Here's a link to the other forum post where I shared a custom data universe example. 2. Correct, more specifically, it's every resolution step within the market hours of the universe's market. For instance, in the example project attached it is a US-Equity market universe, so it will fire a midnight the day after trading, so after Monday's trading, Tuesday at midnight all the way until after Friday's trading which is Saturday at midnight. Likewise, for minute data (no extended hours) it will start firing at 9:31AM and continue until 4:00PM NewYork time. 3. Correct, OnSecuritiesChanged will only fire if the securities have actually changed. An interesting point is that you can define multiple universes. If this is done, it will contain all the changes (set union) between the two universes. Another important note pertaining to multiple universes is that one universe can't remove another universe's securities. One thing that will soon be implemented is the ability to define the minimum time a stock will exist in the universe. This will be useful if you require indicators or state that require multiple days to become usable. I expect to have this ready before the end of next week. We've held off on pushing this feature until it was pretty solid, so if you find anything you wouldn't expect please let us know. You may enjoy taking a peek at the various overload here that offer varying degrees of flexibility. For ultimate flexibility you could derive from the Universe type directly, but that's pretty advanced :)

Max_leverage_yolo INVESTOR

so we can simulate the s&p500 by setting top 500 by market cap?

The coarse data set does not currently include a figure for market cap, but you can simulate the sp500 by taking the top 500 stocks by daily dollar volume.

Nat Miletic INVESTOR

January 2016

Great work Michael. Will the list of universe selection data points be expanded at some point? Trying to back test the Dogs of the Dow strategy and require yield. Thanks!

QuantConnect | January 2016

@Nat -- Yes! We started with this simple data-set but will expand it with other fundamental values in the next few months.

Travis Teichelmann INVESTOR

February 2016

When I add the top method to Initialize I receive a message that OneBillion doesn't exist in the current context. I've tried changing it to an integer and looking for members that in DollarVolume property but couldn't find anything. Any thoughts?

You can add const decimal OneBillion = 1000m*1000m*1000m;. It's just a constant to find stocks with volumes over a billion, Likewise, you could change the volume filter to anything you like!

1 person upvoted this

Perfect! Thank you for updating the code. I modified what you provided to filter the securities based on price. Now all I need to do is implement a gap up and gap percentage method then I can move on to other parts of my algo. Here's what I did.

2 people upvoted this

Stephen Oehler INVESTOR

So this might be a dumb question, but can you apply indicators to the coarse universe selection function? Wondering if I could say, for example, "grab all stocks whose 1-year momentum percent is greater than 10%". :-) Excellent work guys!

Ah found it in an older thread, sorry about that! For those who come here wondering the same thing, here is how you conduct technical analysis in the Coarse Universe filter: https://github.com/QuantConnect/Lean/blob/master/Algorithm.CSharp/EmaCrossUniverseSelectionAlgorithm.cs

Stephen - You can use indicators on the universe selection, that's actually what I'm working on right now. I've been using the link you provided in another post. https://github.com/QuantConnect/Lean/blob/master/Algorithm.CSharp/EmaCrossUniverseSelectionAlgorithm. Community - I've been looking at the LogReturns indicator and found a way to compare the difference in the current price with yesterday's close. Translating those findings into the coarse universe selection is a bit more tricky. Similar to what Stephen was saying, I want to scan the entire universe for stocks that have gapped up. Then scan those to find ones that have the highest gain. This is one of the biggest parts of my strategy and I've been working on it for a while. So if you could point me in the right direction or give me an example that would be fantastic. Best, -Travis

Hey Travis, you don't need to copy all of your indicators into the project. They should be available without adding the file. Sadly the gap open condition requires open and close prices, but the coarse universe data set only has the daily closing price, so I'm not sure you can detect gap up/down on open. If you're just looking for stocks that had the largest one day gains, take a look at this example algorithm. I used the WSJ top gainers page to find stocks that gained the most in one day... and then shorted them!

Hi Michael, Quick question for ya: If you have indicators that are being used within the Coarse Universe Linq statement, are your indicators updated daily or are they updated at the pace of the Universe Resolution? Example of the indicators being declared and updated within the Linq statement: https://github.com/QuantConnect/Lean/blob/master/Algorithm.CSharp/EmaCrossUniverseSelectionAlgorithm.cs I'm getting too-good-to-be-true results in my algorithm. It uses a certain indicator that requires 20 days of daily data. My Universe resolution is set to minute though, and I'm wondering if I'm getting a self-fulfilling prophecy problem here (maybe benefiting from fill-forwarding?).

March 2016

Micheal - Can you backtest live data or is it exclusive to live mode? I've tried to run this algorithm live and made sure the links to WSJ were functional though no trades are being made. I was also inspecting the HTML on the site to find more data to parse. It doesn't seem to be pulling in any data even after I left it running overnight. Trying to run a price filter where d.Price

Hi Travis, I thought I saw someone use custom data with their backtest. Is that the same as "live data" in this case? https://www.quantconnect.com/forum/discussion/418/bubble-algorithm-using-cape-ratio-macd-and-rsi#Item_12 Hopefully I'm not misunderstanding you!

When using indicators in any universe selection function, they will be updated at the same frequency as the universe gets updated. In the case of coarse universes, they will update on a daily time frame. Another thing to note is that we do not apply fill forward to universe selection. If you need more help please post an algorithm demonstrating your issue/concern.

Travis - I'll run the algorithm over this evening with some debugging to see if things are working as expected. Did you make any changes to the example algorithm? I'm not sure what you mean by 'backtest live data.' The NyseTopGainers custom data type is written to support both live and backtesting cases. It supports the backtest case by hitting dropbox (I made a small script to scrape the pages and built a csv from it)

Great, thanks for the validation, Michael!

Clarification on my above statement: We don't apply fill forward to the universe selection data itself, but subscriptions added via universe selection can be set to have fill forward data using the UniverseSettings.FillForward property. This is set to true by default.

Platform

Radically Open-Source Algorithmic Trading Engine

Join Our Discord Channel

Quarterly Open-Source Trading Competition

Draft Discussions

Bookmarked Discussions

SEARCH DISCUSSIONS

360,600 Quants.

VOTE FOR UPCOMING FEATURES

JOIN OUR Community MAILING LIST

IN THIS RESEARCH

PARTICIPANTS

Actions

Join QuantConnect for Free