Rounding issues using MIN, MAX, and TickSize - NinjaTrader | futures io social day trading
futures io futures trading


Rounding issues using MIN, MAX, and TickSize
Updated: Views / Replies:1,967 / 8
Created: by Xav1029 Attachments:1

Welcome to futures io.

(If you already have an account, login at the top of the page)

futures io is the largest futures trading community on the planet, with over 90,000 members. At futures io, our goal has always been and always will be to create a friendly, positive, forward-thinking community where members can openly share and discuss everything the world of trading has to offer. The community is one of the friendliest you will find on any subject, with members going out of their way to help others. Some of the primary differences between futures io and other trading sites revolve around the standards of our community. Those standards include a code of conduct for our members, as well as extremely high standards that govern which partners we do business with, and which products or services we recommend to our members.

At futures io, our focus is on quality education. No hype, gimmicks, or secret sauce. The truth is: trading is hard. To succeed, you need to surround yourself with the right support system, educational content, and trading mentors Ė all of which you can find on futures io, utilizing our social trading environment.

With futures io, you can find honest trading reviews on brokers, trading rooms, indicator packages, trading strategies, and much more. Our trading review process is highly moderated to ensure that only genuine users are allowed, so you donít need to worry about fake reviews.

We are fundamentally different than most other trading sites:
  • We are here to help. Just let us know what you need.
  • We work extremely hard to keep things positive in our community.
  • We do not tolerate rude behavior, trolling, or vendors advertising in posts.
  • We firmly believe in and encourage sharing. The holy grail is within you, we can help you find it.
  • We expect our members to participate and become a part of the community. Help yourself by helping others.

You'll need to register in order to view the content of the threads and start contributing to our community.  It's free and simple.

-- Big Mike, Site Administrator

Reply
 
Thread Tools Search this Thread
 

Rounding issues using MIN, MAX, and TickSize

  #1 (permalink)
Elite Member
Tampa, FL
 
Futures Experience: Beginner
Platform: NinjaTrader, Sierra Chart
Broker/Data: Mirus Futures/Zen-Fire
Favorite Futures: 6E, M6E, 6J
 
Xav1029's Avatar
 
Posts: 1,374 since Dec 2011
Thanks: 1,452 given, 3,354 received

Rounding issues using MIN, MAX, and TickSize

I am working on a new project, and am getting inconsistent results using MIN, MAX, and TickSize. I believe it is a rounding issue, but can't pinpoint it.
 
Code
//Down-Trend
			else if(Phase == "DT")
			{

				dtMin = MIN(Close,TrendPeriods)[0];
				for(int i=0;i<TrendPeriods;i++)
				{
					if(Close[i] == dtMin)
					{
						dtMinIndex = CurrentBar - i;
						break;
					}
				}
				
				if(Close[0] - dtMin >= PullBackTicks*TickSize)
				{
					Phase = "DTPB";
					TrendPlot.Set(-1);
					PlotColors[0][0] = Color.Fuchsia;
					DrawTriangleDown("MyTriangleDown"+CurrentBar, true, 0, High[0] + 2 * TickSize, Color.Fuchsia);
				}
				else
				{
					TrendPlot.Set(-1);
					PlotColors[0][0] = Color.Red;					
				}
			}
PullBackTicks is a double and set to 30 in the following picture:
Please register on futures.io to view futures trading content such as post attachment(s), image(s), and screenshot(s).


Am I missing something? (I have tried drawing the dtMin on the chart, and they seem to be correct)

Reply With Quote
 
  #2 (permalink)
Elite Member
Berlin, Europe
 
Futures Experience: Advanced
Platform: NinjaTrader, MultiCharts
Broker/Data: Interactive Brokers
Favorite Futures: Keyboard
 
Fat Tails's Avatar
 
Posts: 9,651 since Mar 2010
Thanks: 4,226 given, 25,600 received
Forum Reputation: Legendary

If it is a rounding issue, it is related to the use of ">=". Comparing two variables of type double for equity does not make sense. I would try to replace
 
Code
if(Close[0] - dtMin >= PullBackTicks*TickSize)

with
 
Code
if(Close[0] - dtMin > (PullBackTicks-1)*TickSize)

In case that does not help, you would need to find out what is the bar high and bar low of a BetterRenko bar. The bars are backtestable and use real highs and lows, but those highs and lows are not displayed with the brick style.

Reply With Quote
The following 2 users say Thank You to Fat Tails for this post:
 
  #3 (permalink)
Elite Member
@ Germany
 
Futures Experience: Beginner
Platform: NinjaTrader
Broker/Data: Mirus Futures/Zen-Fire
Favorite Futures: FDAX
 
Posts: 439 since Nov 2011
Thanks: 254 given, 368 received


I don't know with which datatype ninjatrader works internally, but in my own tools i use only "decimal". With this type you can define an exact decimal value and all comparisions works like a charm. With double or float you can't describe a decimal value exactly - it's only a approximation. "Decimal" should be used in financial related software products (usually).

Reply With Quote
The following 2 users say Thank You to Koepisch for this post:
 
  #4 (permalink)
Elite Member
Tampa, FL
 
Futures Experience: Beginner
Platform: NinjaTrader, Sierra Chart
Broker/Data: Mirus Futures/Zen-Fire
Favorite Futures: 6E, M6E, 6J
 
Xav1029's Avatar
 
Posts: 1,374 since Dec 2011
Thanks: 1,452 given, 3,354 received


Fat Tails View Post
If it is a rounding issue, it is related to the use of ">=". Comparing two variables of type double for equity does not make sense. I would try to replace
 
Code
if(Close[0] - dtMin >= PullBackTicks*TickSize)

with
 
Code
if(Close[0] - dtMin > (PullBackTicks-1)*TickSize)

In case that does not help, you would need to find out what is the bar high and bar low of a BetterRenko bar. The bars are backtestable and use real highs and lows, but those highs and lows are not displayed with the brick style.

Worked like a charm.

Reply With Quote
The following user says Thank You to Xav1029 for this post:
 
  #5 (permalink)
Elite Member
Berlin, Europe
 
Futures Experience: Advanced
Platform: NinjaTrader, MultiCharts
Broker/Data: Interactive Brokers
Favorite Futures: Keyboard
 
Fat Tails's Avatar
 
Posts: 9,651 since Mar 2010
Thanks: 4,226 given, 25,600 received
Forum Reputation: Legendary


Koepisch View Post
I don't know with which datatype ninjatrader works internally, but in my own tools i use only "decimal". With this type you can define an exact decimal value and all comparisions works like a charm. With double or float you can't describe a decimal value exactly - it's only a approximation. "Decimal" should be used in financial related software products (usually).

@Koepisch: This is an interesting argument. However, a DataSeries of type decimal requires the double amount of RAM compared to a DataSeries of type double. And I am not sure that there are any advantages.

Let us examine the problem above:


1st case: You want to compare today's high to yesterday's high

In case that yesterday's high was 7403.50 and today's high is also 7403.50, you can check for equality and the
expression

(high_yesterday == high_today) = true

becomes true. The expression returns equality, because the two values have been directly written to the variable that holds them. The internal representation of the values is identical, which explains the equality.


2nd case: You want to compare today's high to yesterday's close and yesterday's range (floor pivot R2)

Let us assume that yesterday's close was 7303.50, yesterday's range 200 ticks (Ticksize 0.50) and today's high is 7403.50. Now you are very astonished to find out that

(close_yesterday + 200 * TickSize == high_today) = false

The reason here is that the numerical expression on the left side produces a tiny rounding error. The rounding error is due to the internal representation of the value. Not every decimal number has a finite binary representation. An example is

0.1 (decimal) = 0.00011001100110011..... (binary)


Would using decimals have prevented the rounding error?


No.

Due to the higher precision, you would have got a smaller rounding error, but not the exact value. For variables of type double and float, never compare two values for equality. This is FORBIDDEN. If you want to check for equality you can use a small epsilon value and check whether

Math.Abs (value1 - value2) < epsilon

In the case above any epsilon < 0.5 * TickSize would have done.

Reply With Quote
The following 2 users say Thank You to Fat Tails for this post:
 
  #6 (permalink)
Elite Member
@ Germany
 
Futures Experience: Beginner
Platform: NinjaTrader
Broker/Data: Mirus Futures/Zen-Fire
Favorite Futures: FDAX
 
Posts: 439 since Nov 2011
Thanks: 254 given, 368 received

Thats right @Fat Tails. Here are the truth: "decimal" is internal based on Base 10, which isn't native supported to processor. This slows down the execution (10 times slower then double). Since real literals are in base 10, "decimal" can precisely represent numbers such as 0.1. BUT NO real number value type can precisely represent a fractional number whose base 10 representation is recurring. You have to handle comparisions in a special manner. For instance with overloaded comparision operators. Because the performance impact is small, you should use "decimal" in your own tools. If Ninjatrader goes a other way you should do it also in your indicator/strategy development. But you should know the differences.

Because 7303.50 + 200 * 0.5 = 7403.5 (not recurring) the "decimal" appoach should give the precise value and the comparision should be TRUE.

Reply With Quote
The following 2 users say Thank You to Koepisch for this post:
 
  #7 (permalink)
Elite Member
Berlin, Europe
 
Futures Experience: Advanced
Platform: NinjaTrader, MultiCharts
Broker/Data: Interactive Brokers
Favorite Futures: Keyboard
 
Fat Tails's Avatar
 
Posts: 9,651 since Mar 2010
Thanks: 4,226 given, 25,600 received
Forum Reputation: Legendary


Koepisch View Post
Thats right @Fat Tails. Here are the truth: "decimal" is internal based on Base 10, which isn't native supported to processor. This slows down the execution (10 times slower then double). Since real literals are in base 10, "decimal" can precisely represent numbers such as 0.1. BUT NO real number value type can precisely represent a fractional number whose base 10 representation is recurring. You have to handle comparisions in a special manner. For instance with overloaded comparision operators. Because the performance impact is small, you should use "decimal" in your own tools. If Ninjatrader goes a other way you should do it also in your indicator/strategy development. But you should know the differences.

Because 7303.50 + 200 * 0.5 = 7403.5 (not recurring) the "decimal" appoach should give the precise value and the comparision should be TRUE.

@Koepisch: Thank you again for your answer, but ....

... probably a simple division by 3 would turn your wonderfully exact decimal number into something that has no finite representation. And you are back to case 1. Why should NinjaTrader use a data type, which slows down calculations by a factor 10 and has higher RAM requirements, if in the end it does not cure the problem?

Clean code should not check for equality of two variables, whether they are of type double or decimal. You need to define an epsilon an check the absolute amount of the difference of two values for being smaller than epsilon.

I only check for equality when the values are integers or booleans.

Further the use of decimals goes against the architecture of NinjaTrader. All the DataSeries and PlotSeries objects are based on the data type double.


Last edited by Fat Tails; September 14th, 2012 at 09:36 AM.
Reply With Quote
The following user says Thank You to Fat Tails for this post:
 
  #8 (permalink)
Elite Member
@ Germany
 
Futures Experience: Beginner
Platform: NinjaTrader
Broker/Data: Mirus Futures/Zen-Fire
Favorite Futures: FDAX
 
Posts: 439 since Nov 2011
Thanks: 254 given, 368 received

Thats right, the important issues (with ninja) are, that you know

1. a double is only a approximate representation of a real value
2. if you do math with real value types, the rounding differences increases at every step (mostly)
3. you can't use the "==" comparision operator with real type values at all (@Fat Tails laid down a proper way)
4. Ninja uses "double" so you use "double" too and you have to be cautiously due to rounding deviations

If you are a C# developer you should additionally know that
1. there is a real value type "decimal" which is based at base 10 and is precise at all numbers except if the number represent a fractional number whose base 10 representation is recurring
2. you can't use the "==" operator with decimal too
3. you can overload the "==" operator in custom types, to keep the code clean
4. "decimal" was build for financial calculations
5. the MATH functions don't cover "decimal" types at full extent
6. it is your task to decide when to use "double" and when to use "decimal"

Koepisch

Reply With Quote
The following 2 users say Thank You to Koepisch for this post:
 
  #9 (permalink)
Trading Apprentice
Aix-en-Provence, France
 
Futures Experience: Intermediate
Platform: Ninjatrader
Favorite Futures: Currency Spot
 
Posts: 5 since May 2013
Thanks: 0 given, 0 received

Sorry to resurrect an old thread, but I wanted to question this "decimal value type makes your code 10 times slower than when using real data type" claim.

I have a complicated indicator in development that is more than 2300 lines of code (just my own code; not including the "NinjaScript generated code." I have used the decimal datatype throughout because it makes the accuracy of the results much easier to guarantee. When grabbing prices or other data from the chart, I always convert from double to decimal, and all internal calculations in the indicator use decimals. There are hundreds of these decimal datatypes; many of them are arrays. A typical test of the indicator on several years of minute data will involve many millions of calculations.

I created a test indicator that is identical to the original except that doubles were used throughout instead of decimals. I used the Stopwatch datatype to test the execution speeds of the two versions.

On an extremely long backtest run on 12 years of minute data, which generated over a thousand trades over this period, the double version completed the run in about .145 seconds. The decimal version completed it in 0.587 seconds, about 4 times slower. (I averaged 10 test runs to get an accurate timing; the standard deviations in the timings were tiny.)

Normally I do not have such large backtests with so many trades. A typical backtest will generate about 100 trades. On a test like this, the difference was much smaller. The double version completed the test in around 0.1 seconds, while the decimal version completed it in 0.18 seconds, about 1.8 times slower.

I would say from these tests that using decimals will slow everything down by 10x is a big exaggeration. Note also that I had a big difference in the accuracy of my results. The number of trades and the performance of the backtest differed by between 1% and 5% when comparing the double version to the decimal version, and the difference there is all due to the inaccuracy of the double datatype. Now of course I could recode everything to try to minimise the effects of rounding errors when using doubles, but it seems much easier, for a relatively small performance hit, to use decimals. The decimal version will of course use more memory; how much more is not something I measured. I have no shortage of memory (32GB) so this is not an issue for me.

I think whether you use doubles or decimals is something that will vary according to your needs; a "one size fits all" policy here is not a good one. In my opinion Ninjatrader should support both using doubles and decimals internally (in the Dataseries datatype and the like) and allow the individual programmer to make the decision as to which tradeoff is the better one for his or her particular project.

Reply With Quote

Reply



futures io > > > > Rounding issues using MIN, MAX, and TickSize

Thread Tools Search this Thread
Search this Thread:

Advanced Search



Upcoming Webinars and Events (4:30PM ET unless noted)

Linda Bradford Raschke: Reading The Tape

Elite only

Adam Grimes: TBA

Elite only

NinjaTrader: TBA

January

Ran Aroussi: TBA

Elite only
     

Similar Threads
Thread Thread Starter Forum Replies Last Post
Error on calculating min/max value - please check GetMinMaxValue method Big Mike NinjaTrader Programming 8 August 2nd, 2012 07:32 PM
RE: Min/Max Charts in NT zhaozilong NinjaTrader 10 April 16th, 2012 09:20 PM
Stochastics min/max Prediction within range bar gain247 NinjaTrader 24 August 7th, 2011 12:51 AM
alert works on 1-min, but not on 60-min epictetus EasyLanguage Programming 2 May 9th, 2011 03:06 PM
MIN & MAX for last n bars Stem1 EasyLanguage Programming 2 March 14th, 2011 11:23 PM


All times are GMT -4. The time now is 11:03 PM.

Copyright © 2017 by futures io, s.a., Av Ricardo J. Alfaro, Century Tower, Panama, +507 833-9432, info@futures.io
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.
no new posts
Page generated 2017-12-11 in 0.19 seconds with 20 queries on phoenix via your IP 54.145.16.43