Round2TickSize Query

[sburtt]

Hi Support,

I was thinking to use Round2TickSize in my script to ensure entry and stop orders are sent at an exact multiple of the TickSize, but then I came across the below (see quote). Am I correct in sying that NT already does this in the managed approach, therefore it makes no sense for me to include this function?

Thanks for the clarification.

/* Upon order submission, NinjaTrader automatically rounds prices to the nearest tick value.
When debugging, it can be helpful to round values just like NinjaTrader does to see what is happening. */
Print("Send Limit Order to buy at " + Instrument.MasterInstrument.Round2TickSize(sMApric e));
EnterLongLimit(sMAprice, "Long");

[koganam]

Hi Support,

I was thinking to use Round2TickSize in my script to ensure entry and stop orders are sent at an exact multiple of the TickSize, but then I came across the below (see quote). Am I correct in sying that NT already does this in the managed approach, therefore it makes no sense for me to include this function?

Thanks for the clarification.

That would depend on how you are generating the orders. As ONE example, if you are using moving averages, and comparing values, 50.123456789112162 is larger than 50.123456789112161, whereas if you Round2TickSize(), they are equal values, so if equality is being used to generate the orders, then no order will be generated at all in the first case, and an order will be generated in the second.

There is also the matter of mathematical puritanism: if your input data is only accurate to 2 decimal places (which for most equities it is), then any calculation to 15 decimal places is nonsense, quite apart from the fact that you can never transact in the equity, to anything other than the 2 decimal place accuracy. Which is just a long-winded way to say that you should probably always Round2TickSize() before you use the data to generate any decision prior to generating an order/trade-signal.

Just as an aside, and it may have little to do with trading, the need for sensible precision was driven home when I was in engineering school, where an answer to the wrong precision was always marked wrong, for the justifiable reason that by specifying too precise a value, you would unnecessarily drive up manufacturing costs, because parts would have to be manufactured to a closer tolerance than needed, and so would require higher precision, and hence more expensive, manufacturing methods; and more parts that are in fact perfect, would be discarded on quality control inspection.

[NinjaTrader_PatrickH]

Hello sburtt,

Thank you for your post.

Much thanks to koganam for his detailed response on Round2TickSize.

As listed in the quote you provided the order is rounded to the nearest tick size. Using Instrument.MasterInstrument.Round2TickSize() will assist you in calculations that would require rounding values to the exact tick size of the instrument.

Please let me know if I may be of further assistance.

[sledge]

That would depend on how you are generating the orders. As ONE example, if you are using moving averages, and comparing values, 50.123456789112162 is larger than 50.123456789112161, whereas if you Round2TickSize(), they are equal values, so if equality is being used to generate the orders, then no order will be generated at all in the first case, and an order will be generated in the second.

There is also the matter of mathematical puritanism: if your input data is only accurate to 2 decimal places (which for most equities it is), then any calculation to 15 decimal places is nonsense, quite apart from the fact that you can never transact in the equity, to anything other than the 2 decimal place accuracy. Which is just a long-winded way to say that you should probably always Round2TickSize() before you use the data to generate any decision prior to generating an order/trade-signal.

Just as an aside, and it may have little to do with trading, the need for sensible precision was driven home when I was in engineering school, where an answer to the wrong precision was always marked wrong, for the justifiable reason that by specifying too precise a value, you would unnecessarily drive up manufacturing costs, because parts would have to be manufactured to a closer tolerance than needed, and so would require higher precision, and hence more expensive, manufacturing methods; and more parts that are in fact perfect, would be discarded on quality control inspection.

I still wonder, how I had an entry... before my condition happened.

In live - I had if xx>previous high entry of the day... enter.....

Ummm.... so my strategy entered, and I did get a better price of 1 tick... so I can't complain.

But I pulled up a 1 tick chart that evening, and saw nothing happened ever over that price.

This was ES 09-13.

So something funny was happening some where... How could my condition be true if I entered before it happened. Maybe this is related to how my computer received and stored incoming ticks, etc....

Or does ES actually happen off a tick? (.5099999) (I haven't researched this)...

[sburtt]

That would depend on how you are generating the orders. As ONE example, if you are using moving averages, and comparing values, 50.123456789112162 is larger than 50.123456789112161, whereas if you Round2TickSize(), they are equal values, so if equality is being used to generate the orders, then no order will be generated at all in the first case, and an order will be generated in the second.

There is also the matter of mathematical puritanism: if your input data is only accurate to 2 decimal places (which for most equities it is), then any calculation to 15 decimal places is nonsense, quite apart from the fact that you can never transact in the equity, to anything other than the 2 decimal place accuracy. Which is just a long-winded way to say that you should probably always Round2TickSize() before you use the data to generate any decision prior to generating an order/trade-signal.

Just as an aside, and it may have little to do with trading, the need for sensible precision was driven home when I was in engineering school, where an answer to the wrong precision was always marked wrong, for the justifiable reason that by specifying too precise a value, you would unnecessarily drive up manufacturing costs, because parts would have to be manufactured to a closer tolerance than needed, and so would require higher precision, and hence more expensive, manufacturing methods; and more parts that are in fact perfect, would be discarded on quality control inspection.

Buddy, thanks for taking the time to answer to my query. I am trading mainly forex, hence looking at more decimals than in the equity case, and more precisely I was thinking to use the Round2TickSize() fuction to round the value of the High or Low for my entries, something like this:

EnterLongLimit(High[1], "Long")

but given the quote from NT help page on the use of this fuction I suspect the managed approach already rounds the High[1] to the closest TickSize. Or is my assumption incorrect?

[koganam]

Buddy, thanks for taking the time to answer to my query. I am trading mainly forex, hence looking at more decimals than in the equity case, and more precisely I was thinking to use the Round2TickSize() fuction to round the value of the High or Low for my entries, something like this:

EnterLongLimit(High[1], "Long")

but given the quote from NT help page on the use of this fuction I suspect the managed approach already rounds the High[1] to the closest TickSize. Or is my assumption incorrect?

I believe that bar data is itself rounded to tick size: after all it is the raw data of price that is coming in. One would think, therefore, that there should be no need for any data validation there. The price is the price, period.

[koganam]

...
In live - I had if xx>previous high entry of the day... enter.....

QED? That would depend on what xx really is. How was it calculated?

[eDanny]

Not always

Unfortunately price is not always price. Some poorly constructed bar types will show current price out to 15 decimal places or whatever. This can play havoc when you are checking price against something else for your decision making.

Dan

[NinjaTrader_PatrickH]

Hello All,

Thank you for your posts on this item.

NinjaTrader will round the price to the tick size if the data is already, some data feed providers will provide the price data with a much different decimal place. Such as the instrument needing to be xxxx.xx but the data received was xxxx.xxxxxxxxx, NinjaTrader would round the price to the tick size.

The High, Low, Open and Close will all be rounded to the tick size of the instrument. However, some custom bar types may not round the values to the tick size and you could see this effect the OPen, High, Low, or Close.

Please let me know if I may be of further assistance.

[balancenv]

Hello All,

Thank you for your posts on this item.

NinjaTrader will round the price to the tick size if the data is already, some data feed providers will provide the price data with a much different decimal place. Such as the instrument needing to be xxxx.xx but the data received was xxxx.xxxxxxxxx, NinjaTrader would round the price to the tick size.

The High, Low, Open and Close will all be rounded to the tick size of the instrument. However, some custom bar types may not round the values to the tick size and you could see this effect the OPen, High, Low, or Close.

Please let me know if I may be of further assistance.

This may be the case but when you do any math operation (like + or -), there's no guarantee of the result will be rounded to ticksize, so we still need to constantly use Round2TickSize.
On CL (0.01 ticksize), a simple subtraction of a high and another low will get you something like 0.29000000000000625 result.

The next logical question is, how expensive is this call?

[sledge]

QED? That would depend on what xx really is. How was it calculated?

On ES...

In an indicator:

public double highestHigh = 0;
...

highestHigh = High[0];

The indicator turns off at a predetermined time, so that is locked in.

In my Strategy, I check to see if the

	if (   BarsArray[ES][0] > indicator.highestHigh )

So BarsArray for ES might have thrown something other than .25 to be greater than a 1/4 tick.

[sledge]

Unfortunately price is not always price. Some poorly constructed bar types will show current price out to 15 decimal places or whatever. This can play havoc when you are checking price against something else for your decision making.

Dan

4 range bars, in ES, in NT if that matters, also Zenfire.

[sledge]

This may be the case but when you do any math operation (like + or -), there's no guarantee of the result will be rounded to ticksize, so we still need to constantly use Round2TickSize.
On CL (0.01 ticksize), a simple subtraction of a high and another low will get you something like 0.29000000000000625 result.

The next logical question is, how expensive is this call?

The expense of the call should be:

O(n)

[balancenv]

n is what?

[sledge]

n is what?

Well looks like it will be less than O(n)... O(1)?? :-)

Depending on c# inlining to remove function calls might of course make it slightly faster..

http://en.wikipedia.org/wiki/Big_O_notation