Bar generation and time granularity

[FREEN]

This is the most detailed description I find on how bars (second, minute etc) are built in NT8:

Note: Generating bars from imported tick data is done based off of the timestamps of the tick data. Since granularity of the timestamps are down to the second, it is possible that the generated bars do not perfectly match minute or daily bars provided by the data provider as they may utilize granularity more than the second for their own bar generations.

Taken from here: http://ninjatrader.com/support/helpG.../importing.htm

In NT7 I had an issue with this described as bellow:

As I understand, a bar closes only when a trade has occurred. Ie: a 1 min bar can be extended until a tick event. No matter how far or short that minute is extended, this makes a bar a unreliable unit. Now, this wouldn´t be a acceptable in any cartesian system. It would rule out any vector, matrix calculations and systematic link between Euclidean geometry and algebra. Hence, in my opinion NT lack scientific quality. I realize it might be an economists argument that a bar can´t be closed without an actual trade beeing made. However, after 5 years of NT use I´m stil conviced that it would be a superior behaviour to let a bar (empty from tick data), close (get it´s Y value) from the last tick, no matter when it occoured. An x-axis unit MUST be reliable and predictable at all times!!!

My questions are:
- Is my understanding of time bar building/constructs correct?
- Are time bars built the same way in NT8?
- Could you poiint med to any detailed description on how NT is buildning time (sec/min) bars?!

[NinjaTrader_DaveI]

Hello,

I'm not certain where you were told that time-based bars extend beyond their timed limits, but that is not truly the case. Each time-based bar has a pre-defined end time, and will end at precisely that time. For example, if a one-minute bar were to not receive any ticks for the last 20 seconds, then it would simply post a closing price equal to the last tick that had been received.

When looking at time-based bars, you can think of them as representing the price action that occurred within a specific, pre-defined amount of time. That being said, this would not be the case for Tick bars, Renko bars, or other bar types which are not defined by time intervals.

[FREEN]

Thanks for your reply Dave!

I might have misunderstood the details of bar construction. To clearify my issue with the unreliability of bars:

Kindly see the enclosed low volume/tick example of the MOOG stock. A chart with 1 min bars should yield 390 bars/day (NYSE). See the statistics in the upper left corner that gives a "max bars in day=32" and "min bars in day=1" for a 1313 day chart.

If a bar IS created for each minute, why the lack of bars?

[FREEN]

Yet a pic that points out my issue: A high vol/tick stock (Apple) on the same 1 min chart as the low vol/tick stock (Moog).

The bar count of Moog shows no correlation to the X-axis values (time). The bar time stamp does, but after all the concept of bars is (besides price) the most central building block in model (indicator) code. The indepedant variable from wich dependant variables are built.

I could refrase my query; How do I get total reliability that a 1 min chart (DataSeries) is built with 390 bars/day (NYSE) no matter what?

However, after 5 years of NT use I´m stil conviced that it would be a superior behaviour to let a bar (empty from tick data), close (get it´s Y value) from the last tick, no matter when it occoured. An x-axis unit MUST be reliable and predictable at all times!!!

[NinjaTrader_DaveI]

Actually, it appears that I was the one who misunderstood, so I apologize for the mixup. I thought we were talking about a currently forming bar not actually being able to close without having a tick at or past the close time of that bar. In that specific case, the currently forming bar would indeed close at the last price that had been received.

In the case that you are referring to, however, we're looking at a different story. If no data is received at all during a particular time period, then there will not be anything to draw. While I absolutely see your point about indicator calculations, from a technical standpoint, a time-based bar represents the movement of price during a particular time period, so if there is no price movement during that time period, then drawing anything at all for that bar "slot" would be inaccurate.

The only way to get around this would be to create your own custom Bar Type, which would do something like persist the value of the last received tick, and use that to paint each bar for which no real data came in.

[FREEN]

The only way to get around this would be to create your own custom Bar Type, which would do something like persist the value of the last received tick, and use that to paint each bar for which no real data came in.

Perfect! Happen to know if someone did this type of bar accesable in the file sharing? Suggested readings if in NT7? Additional NT8 features in the issue that alone would be reason for migrating?

[NinjaTrader_DaveI]

I have not personally seen such a bar type created before. If you did want to go this route, then NinjaTrader 8 would be the way to go, since NinjaTrader 7 does not directly support custom bar types to the extent that NinjaTrader 8 does.

I should note that it takes a bit of advanced experience to work with bar types in NinjaScript, but if you really have your heart set on it, you should be able to find a contractor who could take on the job.

[FREEN]

The only way to get around this would be to create your own custom Bar Type, which would do something like persist the value of the last received tick, and use that to paint each bar for which no real data came in.

Dave, you get me right and I agree this would be my workaround.

I´ve been looking into to the ninja script documentation and custom bar code to get some hints. The bars all seem to rely on "OnDataPoint()" that I guess is triggered by reading ticks from the database or from the live datastream? I would need something like an "OnTimeTick()" to make the bars time event driven rather than tick event driven.

Any such time event driving capabilities built into NT? Else I guess my solution will be to read the x-axis time properties and "fit" the database price data into those "true" time bars.

[NinjaTrader_DaveI]

There are not any time-driven events provided in NinjaScript specifically, but perhaps you could devise a way of working with .NET Timers or DateTime objects to track the passage of time in your code.

[FREEN]

Thanks, yes that´s what I´m looking into. In the traders world it seems time stands still if no trades are made : )... The more I dig into this, the more of a flaw in the NT construct it seems. I´ll work around this somehow.

[FREEN]

I dodged this by making a program that modifies exported data so that all seconds are guarateed to have tick data. Seconds with no "real" tick data get their price from last occouring tick, but with volume = 0.

This solution also came with the advantage of beeing able to append "new" historic data to "old" so as to build a database file more than 180 days (max for tick data on Kinetic).

This is my solution for a solid database from wich to build models in wich time (x asis data) can be concidered an independant and 100% predictable variable. It´s not a realtime solution.

Anyone in need for the VS solution/code can drop me a PM.