Code to get precise result for difference between 2 prices to decimal places

[GeorgeW]

Hello,
I am trying to code the difference between two prices from a plot, for which I need a precise result. For example, if the prices are 1.7815 and 1.7818 on the plot, I should get an absolute difference of 0.0003, but on some bars I am +1 or -1 out. Neither of the 2 codes below works all the time. I have tried “MidpointRounding.AwayFromZero”, but that gives similar results. From a read of the information online, I think “MidpointRounding.ToNegativeInfinity”(The strategy of downwards-directed rounding, with the result closest to and no greater than the infinitely precise result) would work, but this is not available in Ninjascript. Any ideas would be welcomed.

Values[12][0] =(Math.Abs(Values[6][5]-Values[6][0]));

Values[12][0] =(Math.Abs(Math.Round(Values[6][5],4)-Math.Round(Values[6][0],4)));

Thank you.

[bltdavid]

Use Round2TickSize.

I suggest you define this convenient helper function,

private double Round2TickSize(double Price)
{
    return Instrument.MasterInstrument.Round2TickSize(Price);
}

Which allows you reduce excessive type clutter in your code,

Values[12][0] = Round2TickSize(Math.Abs(Values[6][5] - Values[6][0]));

[bltdavid]

Note that NT8 also offers a RoundDown2TickSize method.

Good historical reading here.

I found the above thread via this Google search expression,
which also found this official reference sample.

[GeorgeW]

Thank you bltdavid for pointing out this method. I've used the NT8 RoundDown2TickSize, and it does improve the results, but I'm still seeing a few that are 1 out. I'll have a look at the official reference sample later to see if there is any way of improving it.
Thanks again.

[NinjaTrader_ChelseaB]

Hello GeorgeW,

Just to confirm, this is not an issue with floating point arithmetic correct?

https://ninjatrader.com/support/helpGuides/nt8/floating-point_arithmetic.htm

[bltdavid]

Hello GeorgeW,

Just to confirm, this is not an issue with floating point arithmetic correct?
https://ninjatrader.com/support/help...arithmetic.htm

That page is entirely inaccurate with regards to the use of double.Epsilon.
Quite simply, the code example using double.Epsilon is ludicrous and wrong.

The value of double.Epsilon (which represents the smallest possible double
value) is always too small for such use.

Use an acceptable tolerance value, not double.Epsilon.

NinjaTrader engineers don't even use double.Epsilon itself. Their undocumented
NT7 Compare function and their NT8 ApproxCompare function use much more
reasonable tolerance values than the supremely ridiculously small value stored in
Microsoft's poorly named double.Epsilon.

Think about it, if double.Epsilon is the smallest possible double value, how can
the code example in that help page ever work?

if (x - y < double.Epsilon)
    .. do something ...

This statement will never ever be true. How can (x - y) be smaller than the
smallest allowable double value? It cannot. This code is stupid.

[NinjaTrader_ChelseaB]

Hello bltdavid,

There are times where a direct comparison will not work even though printing shows the values appear the same. People write in about this, this page exists for a reason, and the code does work. It's an issue with how computers store numbers.

[bltdavid]

Just to confirm, this is not an issue with floating point arithmetic correct?
https://ninjatrader.com/support/help...arithmetic.htm

NT's help page has a direct link to the Microsoft page on double.Epsilon.

That page is official Microsoft documentation. It states,

"If you create a custom algorithm that determines whether two floating-point
numbers can be considered equal, we do not recommend that you base your
algorithm on the value of the Epsilon constant to establish the acceptable
absolute margin of difference for the two values to be considered equal.
(Typically, that margin of difference is many times greater than Epsilon.)"

See that? Even Microsoft is basically saying 'find an acceptable tolerance
for your problem domain, and use that instead of double.Epsilon.'

Chelsea, its pretty clear the NinjaTrader example code,

if (x - y < double.Epsilon)
    // Do something

is flat wrong and should be removed from your help page.

[bltdavid]

There are times where a direct comparison will not work even though printing shows the values appear the same. People write in about this, this page exists for a reason, and the code does work. It's an issue with how computers store numbers.

I know that.

I am well aware of the issues surrounding the comparison of two double values.

I have no problem with the existence of that page.

You have failed to understand my complaint:
I have a problem with the code example using double.Epsilon.

The specific code example code using double.Epsilon is flat wrong.

Do you disagree?

[GeorgeW]

Hello GeorgeW,

Just to confirm, this is not an issue with floating point arithmetic correct?
https://ninjatrader.com/support/help...arithmetic.htm

Hi ChelseaB,

Thanks for your response. I really don't know if floating point arithmetic applies. All I am trying to achieve is the correct result for this type of computation each time, else I cannot rely on it: [(1.1838-1.1832=6)+(1.1839-1.1843=4)]=10. The prices are picked up from a plot which I reference in the code.

[NinjaTrader_ChelseaB]

Hello bltdavid,

I very much disagree. The double.Epsilon is about how far apart the numbers drift. I have used this and it works correctly.

GeorgeW,

The exact issue is that the numbers are rounding unexpectedly? (If you print out more decimals are you seeing this would have rounded in the direction you expect?)
Or is the issue that the numbers are not being stored exactly as expected?

[GeorgeW]

Hi ChelseaB
The instrument is the 6E. The Tick Size for the instrument is set to 0.0001, and what I see on my chart and indicators are prices to 4 decimal places. I would expect when I code the calculations it would only take into account the prices to 4 decimal places, so I am not sure what the exact issue is.

[NinjaTrader_ChelseaB]

Hello GeorgeW,

When you print (1.1838-1.1832)+(1.1839-1.1843) what value is printed?

Is the issue that the print shows a different number or that it does not compare properly?

[GeorgeW]

Hello GeorgeW,

When you print (1.1838-1.1832)+(1.1839-1.1843) what value is printed?

Is the issue that the print shows a different number or that it does not compare properly?

I have looked at one of the bars on the chart. Based on the prices I can see on the chart, I should get a result of 0.0004, but I am getting a result of 0.0003 displayed on the Superdom. When I do a print, without applying Instrument.MasterInstrument.RoundDownToTickSize, I get a result of 0.0003147...to 18 decimal places. When I apply Instrument.MasterInstrument.RoundDownToTickSize I get a print result of 0.0003. But I need it to give me a result of 0.0004 based on the prices I can see on the chart.

[NinjaTrader_ChelseaB]

Hello GeorgeW,

The RoundDownToTickSize would round down.

Do you want to round up instead?

I was able to find a code snippet of this by google searching c# round up decimal.

https://stackoverflow.com/a/13483008