OmniTrader Professional Forum
Omni Pilot Discussion
OP & Renko
33 replies, 21335 viewings
|
OmniTrader Professional Forum
Omni Pilot Discussion
OP & Renko
|
Last Activity 4/26/2019 10:38 PM 33 replies, 21335 viewings |
|
|
| Printer friendly version |
Jim Dean Sage     Posts: 3433 Joined: 3/13/2006 Location: L'ville, GA  User Profile |
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] | ||
| Vinay Regular Posts: 70 Joined: 1/18/2012 Location: Planet Earth User Profile |
[Edited by Vinay on 8/9/2013 5:50 AM] | ||
| Jim Dean Sage Posts: 3433 Joined: 3/13/2006 Location: L'ville, GA User Profile |
As to your questions - 1. I am "driven" to investigate the tools I use to assure they are reliable, and to find workarounds if they are not (if they are important to me). NTB's are important. 2. It has taken a couple hundred hours overall for me to research NTB's generally, specifically test OT's, and develop OLang alternative (correct) solutions. I learned a lot from that, which affects other users. 3. I enjoy helping/teaching, especially when it relates to "core thinking" about how to do things. I like to show people "how to fish" rather than serving a prepared fish dinner. 4. I think it's important for Nirvana to have the flexibility to chart the wisest course for them, and sometimes "pressures" build up in the user base that unknowingly counters that course - so I try to shed light in the matter, insofar as I'm aware and able and free to do so, to help relieve or more usefully redirect that pressure. There are a zillion things that N can work on at any given time - their decisions have to be driven by bottom line considerations. I know for sure that they are aware if the things I've discussed. I know for sure that the fix I've described will solve 95% of the NTB problems. I know for sure that Ed considers NTB's to be valuable and important, moving forward. So, I hope this info helps put perspective on things, and helps people know how and why it's "safe" to use NTB's as they stand now, and what to be cautious about. That was my goal. [Edited by Jim Dean on 8/9/2013 6:24 AM] | ||
| BeachBoy Member Posts: 21 Joined: 7/15/2013 Location: San Diego User Profile |
"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)." Do I need to write an Omni script to modify the data settings you mentioned above? Or, is there an easier way than this? | ||
| Jim Dean Sage Posts: 3433 Joined: 3/13/2006 Location: L'ville, GA User Profile |
If you do it via OLang code ... it will take several thousand lines ... believe me ... been there, done that! | ||
| BeachBoy Member Posts: 21 Joined: 7/15/2013 Location: San Diego User Profile |
I really hope Nirvana to add the simple fix Jim discussed in detail above and enable OP to trade NTB charts. The VOC (voice of the customers) is overwhelmingly clear around the world! | ||
| julesrulesny Legend Posts: 498 Joined: 8/28/2009 Location: NYC User Profile |
Wow. I was just mind twisted with that explanation turning out to be quite a learning experience. Thanks for explaining that in such detail regarding this problem with NTB charts..(not just with OT either.. as it seems to be across many or all platforms..).. Which would then make OT superior in that regard if they were the ones to fix this!! And just a date change! Sounds so simplistic! I'm sure its not though.. I do have some questions - As I'm sure your probably tired of discussing this.. But.. 1 - What was it in Olang that you were able to do, to fix this? Or, perhaps a simpler question - Did you actually code Omnilanguage to compile actual NTB Charts?? (Such as Renko? Point&Figure, etc??).. If that's the case.. I didn't even know that could be done due to some of the constraints.. 2 - As per the fix, you referenced having the ability to put in an exact date - Having this as an option along with loading bars/bars back seems like a very doable fix.. However, if its the construct of bars loaded that causes these issues where when you load up the same bars loaded, your going to get different results period after period.. (being that the first bar the NTB charts are constructed will differ so signals on the Voteline will differ as time progresses.) So.... Lets say a user put in 300 bars loaded today - does his/her BT, testing, Port.Sim., gets tradable signals, etc Then the next day, if he wants to get the same results, what if he put in 301 bars loaded? Followed by 302? 303? .. Thanks, Marc [Edited by julesrulesny on 8/9/2013 5:54 PM] | ||
| julesrulesny Legend Posts: 498 Joined: 8/28/2009 Location: NYC User Profile |
I guess my confusion is how putting in an exact date can fix the issue.. Hard to get my head around.. But, I do understand the concept as I've heard other issues in OT and the differences to using Dates, bars loaded, etc.. Very interesting - I'm stunned you were able to pick up on that! [Edited by julesrulesny on 8/9/2013 6:02 PM] | ||
| Jim Dean Sage Posts: 3433 Joined: 3/13/2006 Location: L'ville, GA User Profile |
First - yes - I actually have coded the entire suite of NTB's using OLang, plus many extra capabilities beyond the normal ones. So far (I keep adding to it) it is over 6500 lines of code. I've created "overlays" that draw the NTB candles on top of the normal charts so you can see both. But there's not much point in discussing this further. It would be a loooong story. Suffice to say it has been one of the most exhaustive/ing OLang projects that I've done. Re the date thing. It's simple. Instead of the curren input for bars to be loaded (not in addition to, not optional, but a replacement), that field goes away and a new one, labelled "starting date" is added, where you fill in YYMMDD. That's the only diff the user would see or do. That change would only need to apply to NTB's - the existing bars input method could remain for TB bars. Behind the scenes, the data-sucker-inner routine would be educated to not just load a fixed number of bars, but rather to keep on loading bars "backwards" from the HRE until a bar appears that is an earlier date than the input date. At that point the loading stops and throws out that one extra bar. The first bar in the series therefore is the first bar for that particular YYMMDD - and all the subsequent NTB bricks are built using that bar as a reference. As time moves forward, whether a day or a month of five years - as long as that input reference date is not changed, the data-sucker-inner routine will just dutifully load in more and more bars, to assure that the starting point remains the same. Of course any time the user CHOOSES to change the date he can, but in doing so he will be consciously deciding to allow the bricks to change and the signals that are derived from them. So if changes occur, it's under the users control rather that being an unpleasant surprise periodically. Hopefully that clears it up. I'm sure that N can implement it, but since that data engine is a "core" tool they can't just do it as a bandaid patch. I do know there are a lot of other data related things in the works - Forex is one and folding together intraday Test Profiles with EOD to something much easier to work with. So hopefully this will get fixed at the same time. [Edited by Jim Dean on 8/9/2013 9:41 PM] |
|
|
|
|
Administrator
Forum Moderator |
Registered User
Unregistered User |
 E-Mail this thread to a friend |
Toggle e-mail notification |
