QuantConnect paradim comparison with NinjaTrader

Welcome Michael! We have OnData which is triggered on time or data steps (if you set fill forward to true it will trigger on each time step). We have order tickets so you can assign event handlers to specific order fills, or you can bind to the OnOrderEvent method which is the general handler. We try to follow modern C# programming paradigms, while also making familiar patterns like NT/MT4 available to those who want them :) You can see the data events in any of the community algorithms / algorithms in the QC University.

I see - so you have a default method which can always be called (more processing intensive) and you place an order with the broker which would trigger an event in the delegate event handler. That's interesting and opens up hybrid manual/auto trading systems which only supply campaign management rules. What would you say are your main advantages in comparison with a product like NinjaTrader? Elevator pitch if you will - please feel free to point me to pertinent documentation which may already exist. Thanks in advance.

Anyone else want to chime in?

NT and QC both have lots of indicators, algorithms, brokerages so the main advantages are probably: - Naitive coding in multiple languages - Free open source project so no lock in - Import full math libraries from languages - Web based development and live deployment - We support equities, forex and will soon support futures and options. - Importing custom data for indicators or signals, from external sources (e.g. dropbox) - Universe selection - scanning all 9000 tickers for matches (e.g. stocks with price above 200day ema) and have them funneled into algorithm. Check out the docs for more info, quantconnect.com/docs

Well, that all sounds extremely appetizing, Jared. Will most definitely look under the hood and run a few tests.

A few more thoughts if you guys will humor me: In NinjaTrader everything is a series - even NT8 uses a typed array (double) where you access a series like this: Closes[0][0] - this would be the current bar of the first series. Closes[1][0] - this would be the current bar of the second series. Now in my strategies I often use the first Closes/Highs/Lows/Opens series for the candles that drive my chart rules engine. But for execution and especially for historical execution I'm using the second series and assign it tick data. So Closes[1][0] would actually be the current tick. It's an NT work around of course as a tick is a point as someone already pointed out above. Highs[1][0] would get you the very same value. One is able to filter out a particular series like this: if (BarsInProgress == 0) { if (FirstTickOfBar) DoSomething(); ... } As you can imagine this can get messy quickly. I'm used to that paradigm by now but there are certain issues which affect live vs. historical tape. For example in historical tape the current Closes[0][0] bar (e.g. an hourly series) is the PREVIOUS (already closed) bar and the latest Closes[1][0] tick bar is actually the ONGOING bar. They reason they do that is because you can't have say Highs[0][0] unless you know the entire bar. However in live tape Closes[0][0] is the ONGOING bar as well and thus in live tape I have to switch the index from 0 to 1 when evaluating the last closed/complete candle. This is when their paradigm kind of breaks down and things get nasty in a heartbeat. NinjaTrader crashes quite a bit, at least NT7 does under more complicated strategies, so picking up an ongoing campaign is very important, which is why I spent quite a bit of time implementing code that would try to restore an ongoing campaign. However things get nasty quickly and there are never guarantees that you can retain the same state. Just try to calculate position sizing based on account size - well, a day later your account size changed and thus you need to persist the ongoing campaign's units somehow because you can't recalc the position size. If you don't then you have a 2nd campaign on your hand and the old one needs to be closed manually. Just to give you a little taste of the issues we've been facing. I run a trading signal which serves several client accounts via LAMM - it is extremely difficult to guarantee an error free run due to all these types of issues. How would I handle something like this in QuantConnect? If I have candle patterns that I evaluate like I used to via Closes[0][0] I need to check those at the close of the first series. If I want to know if the previous bar (not the open one) was a hammer then I assume I use TradeBars, right? That information may now trigger logic that tells my tick series to entry at a particular price - let's say at the breach of the high of the hammer (or low of shooting star). Clearly that is something where I will need ticks. The issue in NT in particular is that in historical testing the system breaks down with tick data and that's the ugly truth. If I use more than a few weeks of tick data it takes hours on a super fast number cruncher and potentially days on a regular dev system. But that's theoretical as it usually just crashes and wastes your time - I have spent years trying to make it work and in the end I just gave up on tick data. My current work around is to use 1-min bars in back testing instead of tick data. I also implemented my own backtester because I require testing via R sizes which NT doesn't support AFAIK - maybe NT8 does. It kind of works but clearly they are a ton of issues and I once again had to find work arounds. Would you expect QuantConnect to perform better here? How does it internally handle the huge amount of tick data when back testing more than a few weeks? Is it possible to define position sizes in R and test accordingly? Not having touched QC my assumption is that there is less of a focus on charts and more on data processing and execution. I welcome that approach but wonder if it's still possible to show basic charting and implement indicators for visualization. Many thanks in advance for any insights.

I wouldn't recommend approaching it with old/NT ideas in mind. It is probably best to start from scratch and more fundamentally ask what you're trying to achieve. On the algorithm concept level; what are you trying to achieve? e.g. Trigger signal when X-candle pattern emerges on minute chart? or Feed low resolution data into your engine and evaluate on each new point some longer term pattern? Check out the candle stick pattern helpers. We've written support for almost all TA Lib indicators. You can use those classes as you like, or use the automatic indicator data updater system to simply generate signals for the last emitted bar. https://github.com/QuantConnect/Lean/blob/master/Algorithm/CandlestickPatterns.cs

I think I'll just have to jump into the water and run through a few examples. Yes, the candlestick patterns would definitely help develop an understanding how things tick in QC. Thanks Jared.