NexusFi: Find Your Edge


Home Menu

 





The Truth: NinjaTrader


Discussion in NinjaTrader

Updated
      Top Posters
    1. looks_one Fat Tails with 120 posts (165 thanks)
    2. looks_two Big Mike with 54 posts (93 thanks)
    3. looks_3 MetalTrade with 43 posts (10 thanks)
    4. looks_4 ZTR with 41 posts (25 thanks)
      Best Posters
    1. looks_one AynRandFan with 34 thanks per post
    2. looks_two Big Mike with 1.7 thanks per post
    3. looks_3 Fat Tails with 1.4 thanks per post
    4. looks_4 NinjaTrader with 0.9 thanks per post
    1. trending_up 356,171 views
    2. thumb_up 802 thanks given
    3. group 145 followers
    1. forum 1,059 posts
    2. attach_file 65 attachments




 
Search this Thread

The Truth: NinjaTrader

  #731 (permalink)
 Tarkus11 
East Coast
 
Experience: Beginner
Platform: Ninja
Trading: ES, NQ
Posts: 124 since Apr 2010
Thanks Given: 55
Thanks Received: 80

It would make sense to have all un-editable indicators have a BarsRequired = Period assignment, since users can't alter the code anyway.

Of course, when you code yourself, you would be responsible for your own check. I always add

if (CurrentBar < "LengthVarName") return; at the top of my OnBarUpdate().

Reply With Quote

Can you help answer these questions
from other members on NexusFi?
ZombieSqueeze
Platforms and Indicators
Build trailing stop for micro index(s)
Psychology and Money Management
Online prop firm The Funded Trader (TFT) going under?
Traders Hideout
NexusFi Journal Challenge - April 2024
Feedback and Announcements
Ninja Mobile Trader VPS (ninjamobiletrader.com)
Trading Reviews and Vendors
 
  #732 (permalink)
 
Fat Tails's Avatar
 Fat Tails 
Berlin, Europe
Market Wizard
 
Experience: Advanced
Platform: NinjaTrader, MultiCharts
Broker: Interactive Brokers
Trading: Keyboard
Posts: 9,888 since Mar 2010
Thanks Given: 4,242
Thanks Received: 27,102


Tarkus11 View Post
It would make sense to have all un-editable indicators have a BarsRequired = Period assignment, since users can't alter the code anyway.

Of course, when you code yourself, you would be responsible for your own check. I always add

if (CurrentBar < "LengthVarName") return; at the top of my OnBarUpdate().


You can easily alter the code of any system indicator and then

-> save it under a new name
-> and compile it via F5

Doing this you can replace for example EMA, SMA, RSI, MACD by modified versions tkEMA, tkSMA, tkRSI, tkMACD and use those instead of the system indicators.

Reply With Quote
  #733 (permalink)
 eman 
Galveston ,TX
 
Experience: Intermediate
Platform: NT7
Broker: Zaner
Trading: Futures
Posts: 386 since Mar 2010
Thanks Given: 364
Thanks Received: 435



Fat Tails View Post
You can easily alter the code of any system indicator and then

-> first save it under a new name
-> and compile ot via F5

Doing this you can replace for example EMA, SMA, RSI, MACD by modified versions tkEMA, tkSMA, tkRSI, tkMACD and use those instead of the system indicators.

i'm pretty sure you can change the original @EMA.cs file and make your changes there, provided you edit outside of NT. this would clearly be unsupported and not-recommended (and everytime you upgrade NT they could be overwritten, not to mention if you mess up EMA then every other indicator that requires/uses EMA could be messed up as well).

cheers,
-e

Reply With Quote
  #734 (permalink)
 
Fat Tails's Avatar
 Fat Tails 
Berlin, Europe
Market Wizard
 
Experience: Advanced
Platform: NinjaTrader, MultiCharts
Broker: Interactive Brokers
Trading: Keyboard
Posts: 9,888 since Mar 2010
Thanks Given: 4,242
Thanks Received: 27,102


Fat Tails View Post
A short note on the OpeningRange V31 and Initial Balance Range Bands V31 Indicators.

There are several NinjaTrader bugs that affect the indicator and occur, when you use it on volume or tick bars with very small periods. The bugs are the consequence of a strange use of NinjaTrader time stamps.

Example:

The RTH session for ES starts at 8:30 Central Time. Let us assume that you use a session template, which allows to separate the night session from the day session. The night session ends at 8:30, the day session starts at 8:30. Now for the time stamps the following applies:

Minute Bars: The bar stamped 8:30:00 AM belongs to the night session.

Tick and Volume bars: The last bar of the night session has the time stamp 8:29:59 or earlier. If there are bars that have the time stamp 8:30:00, they belong to the new session.

This solution is not very useful, but contributes to general confusion.


How do I confuse myself ?

Following the strange decision that some bars time-stamped 8:30:00 belong to the prior, and some bars to the following session, there is a number of bugs affecting NinjaScript methods.

Bug #1: If you apply Bars.Session.GetNextBeginEnd() to bars with a time stamp 0f 8:30:00, it will return the session start for the night session. For minute bars this is correct, but for tick and volume bars timestamped with 8:30:00 this is right away false.

Bug #2: When data is loaded from the cache, and there are several tick or volume bars with a time stamp of 8:30:00, they are all qualified as FirstBarsOfSession, so the condition Bars.FirstBarsOfSession is always reutrned as true. So I have had charts with 10 consecutive first session bars.


Solution

The problem that some bars with the time-stamp 8:30:00 belong to the prior and some to the following session will confuse NinjaTrader developers and NinjaTrader users in the same way. The best idea would be to change this.

Although it is certainly possible to correct the NinjaScript methods Bars.Session.GetNextBeginEnd() and Bars.FirstBarOfSession, this would not help users, who will be confused when they have to apply that strange logic.

Example attached: Same problems appear on Better Renko charts, as they are built from ticks as well.


I had waited for Ninajtrader 7.0.1000.5 for these bugs to disappear. I am partly disappointed.

One of the bugs has been fixed - the one that caused multiple first bars of sessions - the other one is still happily living within NinjaTrader.

I am disappointed with this because


-> it is always the users who have to test whether the software works
-> there is an obvious lack of resources, if simple bugs that have been clearly identified cannot be fixed

Just tested, with NinjaTrader 7.0.1000.5 GetNextBeginEnd() still returns the false session start time under the following conditions

-> chart built from tick bars
-> first bar of session bar closes at :00 (the case where the bar belongs to new session for tick but to old session for minute bars)
-> session template with night and day session (ES)
-> first bar of day session

Bug report see this thread: NinjaTrader Support Forum - View Single Post - Counter intuitive time stamps

To reproduce

-> create a small period tick chart for ES (to make sure that the first tick bar after the session begin closes at 8:30:00 CT)
-> apply the session template as per below
-> apply the indicator attached which will identify the first bar of the session and the session start time

Attached Thumbnails
Click image for larger version

Name:	GetNextBeginEnd.jpg
Views:	183
Size:	99.9 KB
ID:	38619   Click image for larger version

Name:	Session Template ES.JPG
Views:	175
Size:	46.1 KB
ID:	38620  
Attached Files
Elite Membership required to download: GetNextBeginEndTest2.zip
Reply With Quote
  #735 (permalink)
 gomi 
Paris
Market Wizard
 
Experience: None
Platform: NinjaTrader
Posts: 1,270 since Oct 2009
Thanks Given: 282
Thanks Received: 4,505

Some info I gathered on Ninja timestamping


Fat Tails View Post
Bug #1: If you apply Bars.Session.GetNextBeginEnd() to bars with a time stamp 0f 8:30:00, it will return the session start for the night session. For minute bars this is correct, but for tick and volume bars timestamped with 8:30:00 this is right away false.

I raised this bug in November, Problems with ticks happening at session EndTime - [AUTOLINK]NinjaTrader[/AUTOLINK] Support Forum, but got the usual "by design" answer....

Actually, the "real" last message from Bertrand was :
gomi, this is by design - the bars are stamped at their end (this has always been the case) - any tick after the 6 AM is counted then towards your newly started session.

Went back to the thread, the last message was edited, and now states :
We plan to have a resolution to this with NinjaTrader 7.0.1000.5.

Nice Edit, guys, so you don't have to advertise that there _actually_ was a bug....



This case also dealt with an issue on the first second ticks, that sometimes were counted and sometime not, and I recently added this one : No data for first second on added time series - [AUTOLINK]NinjaTrader[/AUTOLINK] Support Forum , but I doubt I well get any actual answer....



As of bars TimeStamping, here is THE TRUTH :

Ninja's motto on Bar TimeStamp including ticks happening before the timestamp, so 15:30:00 bar doesn't include ticks happening at 15:30:00, is basically inaccurate. This is true ONLY for
  • Minute Charts, and
  • Second charts with period >1.

For second charts with period=1, the timestamp is actually the one of the ticks, so the 15:30:00 bar is actually the 15:30:00 tick.

For other types, you actually don't know. It depends how the ticks are split. If you are on a tick chart , you can have a lot of bars with 15:30:00 timestamp.



PS : I have another case of Ninja editing or deleting of their messages. In this thread,
BeginTime EndTime timezone ? - Page 2 - [AUTOLINK]NinjaTrader[/AUTOLINK] Support Forum

Last post from Ninja support in November 2009 was :
You are incorrect in your understanding. It's very simple to calculate the Begin/EndTimeLocal from the Begin/EndTimeExchange, the actual date is totally irrelevant. Just DayOfWeek matters. You will see with NTB5.

They actually deleted the post, and let the thread die, but then, a few betas later, the new version was actually implementing the solution I proposed even if I was "incorrect in my understanding".
Is it me or is this message modification habit a rude attitude ? No one says software can be bug free, but you can at least reckon the bugs to the guys who take time to test and raise them instead of calling them morons and correcting the software behind their back...


Reply With Quote
Thanked by:
  #736 (permalink)
 
monpere's Avatar
 monpere 
Bala, PA, USA
 
Experience: Intermediate
Platform: NinjaTrader
Broker: Mirus, IB
Trading: SPY, Oil, Euro
Posts: 1,854 since Jul 2010
Thanks Given: 300
Thanks Received: 3,371


gomi View Post
...
They actually deleted the post, and let the thread die, but then, a few betas later, the new version was actually implementing the solution I proposed even if I was "incorrect in my understanding".
Is it me or is this message modification habit a rude attitude ? No one says software can be bug free, but you can at least reckon the bugs to the guys who take time to test and raise them instead of calling them morons and correcting the software behind their back...


The other trick that I have encountered multiple times with NT support, is that when the analyst working on the thread is tired of dealing with you, he says, in order to continue work on this issue, write me by email to support attention so-and-so. Then they give you one of the standard textbook dismissals in private by email, instead of in the public eye of the forum.

Reply With Quote
  #737 (permalink)
 kashter 
Moving
 
Experience: Intermediate
Platform: NT
Broker: Mirus/Zen Fire
Trading: ES
Posts: 82 since May 2010
Thanks Given: 90
Thanks Received: 44

It is my belief because of people like Gomi and FT that Ninja has a wider user base. And I for one, am very thankful. When I was choosing a platform to trade futures with, I relied in part on the user base to influence my decision. The last platform I used was pathetic, partly because it 'ignored' its users input.

Somehow in NT's case, I feel that they DO listen just not showing it/also struggling to keep up. Though Ray and co could do a little better by acknowledging the input/feedback and critique from its users, and especially the technically gifted amongst them. After all, the majority of users benefit when NT takes serious considerations of the items raised. It is because of the efforts of these few people that I am grateful and happy to use NT as a trading platform. Oh, if it wasn't for Gomi's contribution, I would have been with IRT in a heartbeat!

Just a suggestion to Ray/NT, maybe get your product manager, if you have one, to handle such matters. It may seem NT lacks a dedicated 'effort' to manage this, IMHO.

K


gomi View Post
Is it me or is this message modification habit a rude attitude ? No one says software can be bug free, but you can at least reckon the bugs to the guys who take time to test and raise them instead of calling them morons and correcting the software behind their back...



Reply With Quote
  #738 (permalink)
 
Fat Tails's Avatar
 Fat Tails 
Berlin, Europe
Market Wizard
 
Experience: Advanced
Platform: NinjaTrader, MultiCharts
Broker: Interactive Brokers
Trading: Keyboard
Posts: 9,888 since Mar 2010
Thanks Given: 4,242
Thanks Received: 27,102

I do not believe that this issue has to do anything with customer relations. The customer support acknowledged the problem and also has proposed a solution with the new release. This is really a technical discussion regarding some ticks at the beginning of the session. Both problems I brought up have been dealt with, as expected. I was just not very happy with the outcome, as there was no direct solution to the problem.

As it is technical I will try to explain how an architectural decision complicates some of the functionalities that were added later.

Design: A minute or second bar with a time stamp of 8:30:00 contains trade data from a period prior to 8:30:00. A bar built from tick data with a time stamp of 8:30:00 contains trade data from a period prior to 8:30:00. This design feature is counterintuitive and responsible for some bugs that were introduced, because complexity is always punished, whether you develop a piece of software or a trading system.

Consequence: The method GetNextBeginEnd() uses the timestamp of a bar to determine the session start time and session end time of the current session. So if the timestamp of your bar is 8:30:00, what shall this method return? The start and end time of the session prior to 8:30:00 or the start and end time of the session starting at 8:30:00?

Problem: The method does not know what to return, until the underlying bar series is specified. If the bars are fixed period bars, the prior session should be returned, if the bars are built from tick bars, the following session should be returned.

Solution: Specify the underlying bar series. This solution was actually adopted by creating a new overload, which uses the underlying bar series. I must admit that I could not read from the release notes that a new overload was introduced, as I had no clue what they meant with signature. I just used my old indicator to check whether the problem persists. So there is a solution that can be implemented now, but I will have to change the code of all my session related indicators (at least 20), you will get the update notifications.

So this whole thing is not a customer support but a design question. This is the fundamental problem, the last three digits representing milliseconds:

tick bar completed at 8:29:59:950 -> time stamp rounded down to 8:29:59:000 (?)
tick bar completed at 8:30:00:450 -> time stamp rounded down to 8:30:00:000 (?)
minute bar completed at 8:29:59:000 -> time stamp displayed as 8:30:00:000 (?)

So it is an issue of rounding timestamps of bars built from ticks to the full second. Possible solutions:

(a) round them all up to the full second
(b) round them all down to the full second
(c) round them up and down, depending whether the ticks were detected prior to or after 500 milliseconds of the second interval have elapsed.

It is clear that solution (a) would have caused no problems, as both minute and tick bars could be treated in a similar fashion.

However, solution (a) has not been chosen for reasons that I do not understand. This triggered a whole flood of errors made both by developers and customers. Should have kept it simple and stupid.

Reply With Quote
Thanked by:
  #739 (permalink)
 
Fat Tails's Avatar
 Fat Tails 
Berlin, Europe
Market Wizard
 
Experience: Advanced
Platform: NinjaTrader, MultiCharts
Broker: Interactive Brokers
Trading: Keyboard
Posts: 9,888 since Mar 2010
Thanks Given: 4,242
Thanks Received: 27,102

For those who are not interested in details, but want to make sure that their indicators and strategies work correctly on bar series built from tick charts (this includes tick, range, volume, renko, etc. charts)

Please replace

 
Code
GetNextBeginEnd(DateTime time, out DateTime sessionBegin, out DateTime sessionEnd)
with the overload

 
Code
GetNextBeginEnd(Bars bars, int barsAgo, out DateTime sessionBegin, out DateTime sessionEnd)
The original syntax is flawed, as it does not take into account the bar type, on which the method is used. Do not use the new overload outside OnBarUpdate().

Reply With Quote
Thanked by:
  #740 (permalink)
 dutchbookmaker 
NYC
 
Posts: 187 since Dec 2010


Just having started getting into Ninja 7 I think some of you guys may be not seeing the forest for the trees. If you have used it for years I could see how the issues that would only effect a smaller % of the user base would be frustrating if they are messing with your own work but the scope of this project is really pretty amazing.
Everything else has pretty much been left in the dust IMO. By version 8 or 9 it will be game over.
I'm sure I will run into issues but that is only because there are things I should be able to do with Ninja that I wouldn't have even bothered to contemplate with other retail trading software.
Not running into bugs because you don't bother to do something with the software is not a "feature".

Reply With Quote




Last Updated on April 22, 2017


© 2024 NexusFi™, s.a., All Rights Reserved.
Av Ricardo J. Alfaro, Century Tower, Panama City, Panama, Ph: +507 833-9432 (Panama and Intl), +1 888-312-3001 (USA and Canada)
All information is for educational use only and is not investment advice. There is a substantial risk of loss in trading commodity futures, stocks, options and foreign exchange products. Past performance is not indicative of future results.
About Us - Contact Us - Site Rules, Acceptable Use, and Terms and Conditions - Privacy Policy - Downloads - Top
no new posts