Jim Dean Sage     Posts: 3433 Joined: 3/13/2006 Location: L'ville, GA  User Profile | In answer to VXP's question … NTB's are very useful windows into the market. Each of the five types that OT provides has its own perspective and benefits. OT is set up to use them like TimeBased (TB) bars, so that indicators, systems, filters, stops and strategies can be applied to them with ease. But the way they work in OT (and afaik in most other platforms) has a significant Achilles heel. If you use NTB's for actually driving your mechanical trading rather than treating them as a generally informative window into the market for discretionary trading, then you will find that they "trip you up" with some regularity. Why? Because the bricks CHANGE as time progresses forward. I'm not referring to the natural progression of one days price action to the next day. I am referring to how a brick with a particular OHLCV and a known Start date/time and End date/time, will CHANGE in the future to have a different set of one or more of those seven attributes (brick is the term for an NTB candle, while bar refers to the underlying TB candle that the NTB is built from). This happens in all trading front ends that I have seen which support NTB's, including OT, and it is easy to understand why it happens. It's also easy IMHO to FIX so it doesn't happen, but that's another story. Why does it happen? The reason is that a chart full of NTB bricks are ALL DEPENDENT ON THE FIRST UNDERLYING BAR that begins the series. Each NTB brick is calculated using precise rules and formulae from the price action of the preceding TB bars - thus the seven attributes OHLCV and SE date/time are dynamically set for each NTB brick from the calculation - NOT ruled by some universal exchange based feed and atomic clock. Thus the form and pattern of the NTB bricks you see on a chart are dependent on the EARLIEST HISTORICAL BAR that is used to begin the construction. A story to illustrate this … Let's say you are looking at a Renko chart with 5-min underlying bars, 1.5 ATR Close-based bricks on it, and your friend is viewing a chart using the same NTB settings on the same symbol based on the same data feed. As you talk on the phone with your fried about the charts you are looking at, you get confused. What they are saying about what they see regarding the pattern of the most recent 30-50 bricks is somewhat different than what you are seeing. So, you focus down and try to figure out what is going on and you realize when you check each of those bricks, that the bricks on your two charts have different OHLCV &/or SE attributes! So you call a third friend who has the same data feed and OT release and ask them to check their 5-min underlying, 1.5 ATR Close-based Renko chart for that symbol and ARGH! - lo and behold you find that THEIR chart's last 30-50 bricks are different from EITHER of yours. You call five more friends, same story - different bricks for everyone. Along the way, you ask each friend to apply a canned strategy with default parameters to the chart and you examine the VOTELINE over the past hundred bricks or so - and EEK! You find that each of your dozen (worried) friends see somewhat different Entry and Exit signals in the voteline. As you think about it on your conference call, you realize that it only makes sense the signals and exits would be different, since the bricks that they are built from are different. And you all decide that something's wrong with the NTB's. So, you decide not to use them for trading until the problem is resolved. Wise decision! This is a "relatively true" story. All it's missing is the reason WHY. And that reason is simple - the clue was given earlier in the explanation. Did you notice it? Can you guess how that big group of people could all be seeing different bricks and signals and exits at the same time? … silence as you ponder … The answer is, that all of the people you called had significantly different settings for the number of historical underlying 5min bars that they loaded, using the Data Periods entry box. They all got the 1.5 ATR Close based part right, and they all were using 5-min bars for underlying, but one person had 300 5m bars loaded, another had 2000, another had 12000, etc - significantly different "depth" of the historical 5m dataseries. So - everyone goes back and changes their 5m setting to have the same number of bars - lets say 400 to keep a full week of history in place - and VOILA! all the bricks and entry exit signals line up PERFECTLY. Problem identified. Workaround discovered. End of difficulty? NO. Because as you all fiddle with this you realize the truth that if the EARLIEST BAR LOADED changes, the EXISTING, historical bricks and the signals also can change with it. … end of the phone call … This is how the very earliest release of OT's NTB's worked - and how NTB's work on many other platforms. After a while N recognized the problem and took steps to repair it, but unfortunately their solution only reduced the frequency of how often these issues appear, but it did not eliminate it. The explanation of what they did is pretty long but I have it all in writing from their staff. In fact, I've modeled the entire thing in OLang (a huge project) to assure that I can see the effect in the code that echoes their logic. What OT currently does is to "temporarily lock in" the starting date/time of the underlying bar that's used as a "reference" for the NTB calc's, so that at the chart moves forward the bricks and signals don't change … very often. But they do change, eventually, since OT's algorithm picks arbitrary points to use as temporary reference and once enough time passes that temporary point "rolls off" the back end of the 5m (or other TB bar) data you've loaded, and WHAM all the bricks change, as do many of the signals and exits. So - the problem is less frequent but it still exists. Nutshell - you can't count on the signals you see on the VOTELINE to remain constant for an NTB chart as time moves forward. Since that is the case, is it any wonder that OmniPilot has not been enabled for NTB's? (Btw I don't know that is N's reason but it's a good one.) The good news is that there is a SIMPLE SOLUTION to this. I've documented all this for Nirvana in great detail, as of a year or two ago. The solution is … drumroll … Modify the Data Settings input for NTB's so that instead of specifying some number of underlying bars to be loaded (as you do, now) - instead, specify a PRECISE DATE that defines how far back historically the underlying bars must extend to. That's it. A very simple GUI change (and some horsing around in the background to get the data loading to be governed by date rather than bar count). Once that is done, you can be fully confident that your chart's bricks and signals and exits will be exactly the same tomorrow as they are today or they were a month ago. And if a group if friends compare charts and vote lines, with the same reference date setting, they will all agree (as long as the data feed is the same). But until that change is made, the problem exists and NTB's are simply not reliable for MECHANICAL trading. They're still very useful for discretionary SBAS (stand back and squint) decisionmaking, but rule based mechanical strats will be unstable. I am 100% sure of all this. I've actually written OLang code to model all five NTB types as "overlays" on the TB bar charts to demonstrate it, and to FIX it. I've communicated all this to N and when they have time I'm confident they will fix it. But it's important IMHO that the users realize both the value and the weakness of the current setup. Let me say again - afaik, N's solution is better in this regard than some other platforms - it just needs one more step to tidy it up. Whew! Long explanation, but you asked. I sure don't want to have to type all that out again! There are btw some other "calculation" and "modelling" errors and issues with more than one of the NTB models (notably Range), but there is no point in addressing that till the "reference bar" issue is fixed. So - my advice is to use the current NTB's as a discretionary window, rather than as a basis for generating specific signals and exits. And be patient till N has the time and resources to fix this. [Edited by Jim Dean on 8/9/2013 4:56 AM] | |
