NT8 misreading bars

[GeorgeW]

Hello,
Are there any known circumstances under which NT8 is known to be occasionally misreading bars or not sending a signal when one would be expected based on the parameters in the code? The reason I ask is because I have 2 bars on a chart when I would have expected an arrow signal, but there was none. So I set up bool series to check if the conditions in my code were true or false. In the 1st instance, all the conditions for an arrow signal were true, but no arrow signal.In the 2nd instance, a bar is marked as false when it is true, and I have examined another bar, which is exactly the same (Close < Open; 1 tick upper wick, 2tick body, 1tick lower tail) , and that is marked as true. The check for that condition was:

if((close0 < open0 && (close0 == low0 || close0 == low0 + TickSize)) || ((open0 == close0) &&((Math.Abs(high0 - open0) > Math.Abs(low0 - open0)))))
				bearClose1[0] = true;

I've spent hours examining my code for errors, but as far as I can see, there are no errors in the code that should be causing this.

Thank you.

[sledge]

I have tracked down one when called from a strategy. Looks unrelated though.

http://ninjatrader.com/support/forum/showpost.php?p=510997&postcount=5

[NinjaTrader_Jim]

Hello GeorgeW,

Thanks for opening the thread.

If NinjaTrader is not triggering code within conditions that are true, we would definitely want to look into this further.

However, we would need to first confirm that you the variables for that condition allow it to become true. We would need to place Print() statements outside and inside the condition to:
1. Print out the variable values used to check to make sure the condition has become true,
2. Print out a message within the condition that says it has become true.

If the prints for these variables shows the condition should become true, and the print within the condition confirms that condition became true, the code within the condition must be executed as well. If it is a drawing object the syntax of that drawing object should be double checked. Orders should be double checked using Trace Orders.

If you have taken the steps above and have been able to determine that the logic is correct and NinjaTrader is not executing some code, please provide a barebones sample that can reproduce the issue so we can analyze it further on our end.

I have linked some resources for debugging and using Trace Orders for reference.

Debugging: http://ninjatrader.com/support/forum...ead.php?t=3418

TraceOrders: http://ninjatrader.com/support/forum...ead.php?t=3627

I look forward to assisting you further.

@Sledge, just as a head up, Jesse is out of the office today. Another teammate or I will try to get to that ticket when we have available time. If we do not get to submit a response, Jesse will be able to reach back when he returns.

[GeorgeW]

Thanks for your reply, Jim.
I am not sure what the difference is between placing a print statement outside and inside the condition. I have set up the conditions certain types of bars or a stochastics condition etc and then placed the print statements after them. I was then able to view the results in the output window.

[NinjaTrader_Jim]

Hello GeorgeW,

Thanks for the reply.

Printing the values of the variables used in the condition before the condition is checked will tell what what is going wrong if the condition is not becoming true.

So I understand the issue correctly, you have a condition that when it becomes true, a drawing object is placed that doesn't draw? You also have a print statement that confirms this code has been reached?

If this is the case, have you confirmed that the syntax for the drawing object is correct? You can find example code in the help guide to reference syntax for the drawing objects you wish to use.

Drawing objects: https://ninjatrader.com/support/help...us/drawing.htm

If you can provide me an example of some code that becomes true and a drawing object with correct syntax is not working correctly, I could take a closer look.

I look forward to being of further assistance.

[GeorgeW]

Hello Jim,

I have further clarified the issue. It is not the draw object that is the problem, as the arrows are being drawn correctly in most cases. It is Ninjascript that is occassionally not identifying a bar correctly. I've seen a couple of examples today, but I'll refer you to the first examples I saw on the 6B on 16/06/2017. The bar at 07:38:09 is a bear bar, but the print to the output window is showing bearCloseBar0 = false. I also try to pick it up from the next bar with bearCloseBar1, but that is also showing false. There is another example at 12:07:37.

I am attaching a simplified version of the code for you to test on your end (no arrow signals included). I have also attached images of the 2 examples I am referring to.

[NinjaTrader_Jim]

Hello GeorgeW,

Thanks for the reply.

If you think the bearCloseBar0 should have been set to true, you will need to verify the condition that sets this value to true actually becomes true in that instance, and allows the code within to execute..

I would suggest to test that period with Market replay data to reproduce so you can easily rewind.You will need to use Prints to verify the values of the condition below so you can verify that the logic allows it to become true.

For example:

if (close0 < open0)
	Print("Set 1 True!");

Each section of that condition will have to be verified so you can deduce if the condition is logically possible in that instance.

As I suggested previously, I would also advise to place a print within that code block so the output window can tell you when if bearCloseBar0 became true.

if((close0 < open0 && (close0 == low0 || close0 == low0 + TickSize)) || ((open0 == close0) &&((Math.Abs(high0 - open0) > Math.Abs(low0 - open0)))))
{
	bearCloseBar0[0] = true;
	Print("bearCloseBar0[0] is true!");
}

If you would like further assistance debugging your code, I could get you connected with a member of our Business Development team who could pass over a list of Certified NinjaScript Consultants who would be happy to help you debug your code. If that is the case, please write in to platformsupport[at]ninjatrader[dot]com with the thread URL and the text "Attention Jim."

[GeorgeW]

Hello Jim,

I have done all the suggested print statements. The bar on 6B on 16 June 2017 at 07:38:09 is constructed as follows:

Open 1.2819
High 1.2819
Low 1.2812
Close 1.2813
TickSize = 0.0001

…if(Close0 < Open0)– correctly identified as true.

The bar closes 1 tick above its low. Consequently:
..if(close0 == low0 + TickSize) This should be identified as true, but it is not. Even if rewritten
..if(low0 == close0 – TickSize) This should be identified as true, but it is not.

There is another example at 12:07:37 on the same instrument on the same day, also on a bar which closes 1 tick from its low. I have also seen a bull example on the 6E on 20/06/2017 at 01:09:02, this time where it was coded to identify the bar if it was a bull close 2 ticks from the high. These are not problems requiring debugging of my script, it is a serious and fundamental flaw in Ninjatrader 8. If you are unable to recognise this or deal with this issue, then can you please put me in touch with someone at Ninjatrader who can.

Thank you.

[Harry]

Hi George,

I would like to point your attention to the fact that you may not check double values for equality. This is a major coding crime!

Floating point values (double and float) need to be considered as approximations and not as exact values. This is particularly true after an arithmetic operation. But even without such an operation, the compiler may use varying precision for different values.

If I look at your code

if(close0 == low0 + TickSize)
if(low0 == close0 – TickSize)

then it is obvious that it cannot work. The value on the right side of the equation is the result of a floating point arithmetic operation and may be different from the left value, even if the prices match.


Solutions for your problem

You have two options to modify that code as needed.

(1) Convert the double values into integers. For example you can divide both the left side and the right side of the equation by the ticksize and then round the result to the next integer. The integers can be compared for equality.

(2) Alternatively you may use two inequalities, for example you can replace

if(close == low + TickSize)   // this is a false statement

with

if(close > low + 0.5*TickSize && close < low + 1.5*TickSize)  // correct statement

The second statement checks whether the approximated value for close falls within a tick range around the approximated value for low + ticksize.

[JerryWar]

I have always used something like
if (Close == Instrument.MasterInstrument.RoundToTickSize(Low+Ti ckSize))
in these situations as I have found the built in vars Close and Low will be already be at an exact TickValue.

[GeorgeW]

Hello Harry,
Thank you for your detailed explanation, which I will use to adjust the code. Does that also mean "close == low" also has to be adjusted as it is a double value being checked for equality?

[NinjaTrader_Jim]

Thanks for providing that explanation, Harry.

@GeorgeW, we have a thread that explains some the implications of comparing doubles and internal floating point math and what you can do about it.

You can find it here: http://ninjatrader.com/support/forum...ead.php?t=3929

To answer your question: yes, you would be risking some sort of inequality if there are significant digits that are not equal. I.e. 1.00000001 != 1.00000002

[GeorgeW]

Thanks for the explanations Harry, JerryWar and Jim. I have tried both Harry's and JerryWar's methods, and I am now getting the signals.

[Harry]

Hello Harry,
Thank you for your detailed explanation, which I will use to adjust the code. Does that also mean "close == low" also has to be adjusted as it is a double value being checked for equality?

"Close == Low" will probably work in most of the cases, however if you want to play it safe, you should make it a habit not to check double values for equality.

You should only check integers and booleans for equality. For double values best use inequalities or convert them to integers first.

I also invite you to look at the code of the Stochastics which uses a method ApproxCompare(0) which is another workaround for floating point comparisons.

Further you should read the Help Guide -> NinjaScript -> NinjaScript Best Practices, which has a section on Floating Point Comparisons.