Price Bar attributes

[Turtle Trader]

Hello,

more newbie questions

• how do I access the high/low/open/close prices of a bar?
• is there a function to tell me if the bar closed up or down without me having to calculate it?

thanks

[NinjaTrader_RyanM1]

Hello TurtleTrader,

The most recent prices are accessed with Index [0]

Open[0]
Low[0]
High[0]
Close[0]

You can use either Rising() or Falling() These functions check an indicators' previous value with its current value. When using these functions with price, you don't need the specific index value as mentioned above.

Rising(Close);

Checks if the most recent close is higher than the previous close.

[Turtle Trader]

reply

What I'm actually looking for is whether the last bar finished long or short from its open.

The current bar is not involved.

If there is no functiton it will be easy to calculate.

[mountainclimber]

Turtle Trader,


Just do:
if(Open[iLastBarIndex] > Close[iLastBarIndex])
{
//do stuff for down bar
}

and...

if(Open[iLastBarIndex] < Close[iLastBarIndex])
{
//do stuff for up bar
}

Where iLastBarIndex is some integer the reference whatever you mean by "the last bar". For example if you mean the last bar is the bar prior to the currently building bar, then iLastBarIndex will be 1.

If you don't know what index the bar you want has, but you know the time/date you can use GetBar(dtSomeTime), where dtSomeTime is a DateTime time stamp for the bar you want. So you have to know the time stamp or the index of the bar. This link will help:

http://www.ninjatrader.com/support/helpGuides/nt7/getbar.htm?zoom_highlightsub=getbar

There is no function that I am aware of...

[DaveE]

A simple compare like (Close[1] > Open[1]) works most of the time. But occasionally you will find the chart and databox show Close=Open but the program test above does not. At least I have experienced this using NT6 with data from IB. I found a difference between the price shown in databox and say Close[0] that was larger than double.Epsilon but still so small as to be absolutely meaningless from a price point of view. In my view any price difference smaller than tick size should be treated as junk.
The chart & databox filters this kind of junk out (presumably by using Math.round to nearest tick), but the simple code above does not.
To avoid this problem you currently need to use MasterInstrument.Compare (or you could do your own rounding).
Josh wrote a useful summary here:

http://www.ninjatrader-support2.com/vb/showthread.php?t=3929

My question to NinjaTrader is:
Why not round all price data (Close Open etc) to the tick size - before exposing it to the user or storing it? (so get rid of any junk thats not visible on chart or databox).

That way users would not need to remember to use the unintuitive MasterInstrument.Compare, but could rely on intuitive code like Close[1] > Open[1] giving results that are always correct for trading.

[Turtle Trader]

precision of prices and calculations

Thanks guys.

The last note confirmed something I've noticed, and that is the precision is not exact sometimes for the price calculation.

I'm still experimenting with this and will post a new thread...but briefly...

I come from a software background writing corporate financial systems.

We NEVER using floating point numbers for financial calculations. Can you imagine if banks did that with your account?

I believe that Double is a floating point and that it is not capable of giving you exact precision when calculating ticks.

I'm a newbie at NinjaScript, but not with software.

I had a problem with one of my strategies because of the ticks were being calculated as a Double. So, I cast the price variable to Decimal and it worked with the precision I expected.

But since all the NinjaScript functions operate on Doubles, it means a lot of work casting back and forth.

There are probably quite a few problems that arise from this issue.

[mountainclimber]

Fair enough ....but if you consider that every data feed is different, the same data feed may have different historical data than it would if you recorded streaming data live, and all systems (at least that I have seen) aren't that accurate anyway: getting down to a super long decimal/float isn't that useful. Its all an estimate anyway....fuzzy numbers. Just go with double most of the time and you will be fine. You want ballpark numbers only 99% of the times.

In your case, the up bar vs down bar may be better defined by excluding a candle that has a narrow range body...i.e. a doji bar of approximate but narrow range. But I don't know your system so I can't say...just try to explain the concept.

my 2 cents, i've been automating this stuff since 2003 and I have a masters degree in finance/investments, i've worked at a trading platform.....so you could say that maybe I have some persective worth listening to...