Posts: 620
Joined: 3/7/2006
Location: Ocean Springs, MS
User Profile Renko Charts are not listed in OP list of charts to trade. IS there a fix for this are a work around. If not when will be fixed.
Thanks
Nick M
Posts: 2305
Joined: 1/1/1900
User Profile OP has not been developed to work on NTB chart types yet. It will likely be added after the holidays.
Posts: 70
Joined: 8/22/2010
Location: Grande Prairie, AB., Canada
User Profile since there has been a release, but this isn't fixed yet. Will this fix be in the following release?
thx,
shawn
Posts: 2305
Joined: 1/1/1900
User Profile We have fixed the issue of OP not working on profiles with NTB in them, but we haven't yet added the capability for OP to trade on NTB. We'll get it though, thanks for your patience.
Posts: 70
Joined: 8/22/2010
Location: Grande Prairie, AB., Canada
User Profile This isn't fixed yet on today's release.
Posts: 2305
Joined: 1/1/1900
User Profile This error was fixed in PR2D. Were you seeing the error on 2D or was it working in 2D & now you're seeing it again on 2E?
Posts: 70
Joined: 8/22/2010
Location: Grande Prairie, AB., Canada
User Profile just to clarify 1st. i want to have O/P trade my Renko chart strategy. With the Renko Charts selected for the trade plan, and added and checked off as a time frame, O/P only lists the main time frame the Renko Chart is based off of, and not the "Renko" time frame.
O/P has never listed the Renko as a tradeable time frame to trade in any release since the 2012 release.
shawn
Posts: 70
Joined: 8/22/2010
Location: Grande Prairie, AB., Canada
User Profile is it possible this gets fixed on the next release or ?
Posts: 2305
Joined: 1/1/1900
User Profile The ability to trade NTBs through OmniPilot has not been added yet. Our next PR will be early next week & will not yet have this capability.
Posts: 70
Joined: 8/22/2010
Location: Grande Prairie, AB., Canada
User Profile Barry... can you give us any update on when we will have the ability to trade NTB charts with OP?
thx,
shawn
Posts: 10
Joined: 10/12/2011
Location: Pretoria , South Africa
User Profile I would also like to know when this will be fixed. Everyone is on the NTB wagon but we're unable to automate it. Please. Sarel
Posts: 70
Joined: 8/22/2010
Location: Grande Prairie, AB., Canada
User Profile I didn't see a response from the last reply above this. We are closing up to 1 Year now since this was said to be handled. We do we stand with OP and NTB?
thx,
Shawn
Posts: 2305
Joined: 1/1/1900
User Profile It was on the OT2013 survey. I don't know if anything has been decided as of yet.
Posts: 114
Joined: 3/2/2006
User Profile Please. . . . Let me add my request that OP with NTB become functional.
Posts: 29
Joined: 3/11/2011
User Profile NTB charts should have been integrated with OP and everything else in OT BEFORE NTB was released. This is like selling a car without a petrol tank, interesting but useless.
Was a survey done regarding what features users want in OT 2013?
Is the survey only sent to some users?
Posts: 2305
Joined: 1/1/1900
User Profile It wasn't an oversight or a bug. NTBs were pretty new to us & a lot of our users, so it was a management decision not to allow Pilot to trade them until we were sure that it was solid & that we had enough time to test it ourselves.
| Was a survey done regarding what features users want in OT 2013? |
Yes.
| Is the survey only sent to some users? |
It was sent to customers that have purchased OmniTrader. If an OT customer didn't receive it, perhaps their email address is not updated in our system, it was filtered to a junk or spam box, or something like that. In your case, I checked your account & we are not sending emails to you by request. If you would like this changed, send me a private message with your current email address & I'll be happy to change it for you.
Posts: 29
Joined: 3/11/2011
User Profile Thanks Barry, much appreciated!
Barry,
I just reviewed the history of this thread and wanted to find out if any progress has been made with allowing OP to trade NTBs. I'm aware of the inherent lag issue of Renko/3 line Bars charts wrt actual price but even with the lag, I have found NTBs to be far superior to trade with than standard bar charts. Any update?
Thanks,
Alan D.
Posts: 2305
Joined: 1/1/1900
User Profile It isn't possible yet, but I'm sure it is only a matter of time until it's added.
Posts: 5
Joined: 10/5/2012
Location: MA
User Profile I am looking for OmniPilot can handle The REnco chart,too.
Posts: 21
Joined: 7/15/2013
Location: San Diego
User Profile I am joining the crowd to enable my OP to trade NTB charts. In my opinion, Nirvana should consider this THE MOST IMPORTANT feature to include in their upcoming release! I hope the voice of the customers matters here.
Posts: 3433
Joined: 3/13/2006
Location: L'ville, GA
User Profile They need to FIX the NTB charts first, before they start taking them further.
And yes, it's very valuable.
Posts: 70
Joined: 1/18/2012
Location: Planet Earth
User Profile Originally written by 210921 on 8/9/2013 7:59 PM
They need to FIX the NTB charts first, before they start taking them further.
And yes, it's very valuable.
They need to FIX the NTB charts first, before they start taking them further.
And yes, it's very valuable.
Jim can you elaborate on the assertion "FIX the NTB charts first"? Are they broken? Lack of functionality is one thing but issues with the existing features is another.
Posts: 96
Joined: 6/18/2011
Location: Sydney, NSW, Australia
User Profile I'd like to add that I'd like to trade NTB using OmniPilot also. John
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.
Posts: 70
Joined: 1/18/2012
Location: Planet Earth
User Profile Jim... I am dumbstruck at the depth of your knowledge and the extent to which you go to understand and explain things. From where you get so much energy and motivation? Hats off to you.
Posts: 3433
Joined: 3/13/2006
Location: L'ville, GA
User Profile As shucks thanks :8
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.
Posts: 21
Joined: 7/15/2013
Location: San Diego
User Profile Thank you very much, Jim. I again admire your in-depth knowledge and passion. You mentioned that ..
"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?
Posts: 3433
Joined: 3/13/2006
Location: L'ville, GA
User Profile It has to be done in house by Nirvana.
If you do it via OLang code ... it will take several thousand lines ... believe me ... been there, done that!
Posts: 21
Joined: 7/15/2013
Location: San Diego
User Profile Got it! Thanks Jim.
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!
Posts: 498
Joined: 8/28/2009
Location: NYC
User Profile Jim,
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
Posts: 498
Joined: 8/28/2009
Location: NYC
User Profile Ok.. As I read your post again - I see that you pointed this out already to some extent.. That once the earliest bar changes, it very possibly will change all your signals, trades, etc.. (Such as too, a user will surely want to change bars loaded at times, and thus it shouldn't cause such major changes to results either.. So, even tho one can always add +1 to bars loaded, in the long run, once the bars loaded changes away from that original date - everything else changes..)
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!
Posts: 3433
Joined: 3/13/2006
Location: L'ville, GA
User Profile Hi Marc
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.