### Input Parameter Rounding

Posted:

**Sat May 07, 2011 2:22 pm**Just an FYI on an obscure issue that probably affects only me, but might be of use to someone out there ...

When you enter a floating / percent parameter value (convert % inputs into decimals i.e. 1% = 0.01), TBB does some rounding:

1) If the number is greater than 10^5, the value is rounded to the nearest integer. 123456.789 -> 123457

2) If less than 10^5 but greater than 10^-4, the number is rounded to 6 significant figures. 123.456789 -> 123.457

3) If less than 10^-4, then the number is rounded to 9 decimal places. 0.00000123456789 -> 0.000001235.

This matters if you use any approach that involves re-setting a parameter value within a test (such as when randomly generating parameter values as part of a genetic search optimization) AND you want to be able to reproduce the results by "manually" entering your parameter values in the system.

It was making me crazy that sometimes my optimized results would agree to the penny, sometimes to the pound, and sometimes (due to the butterfly effect) were quite different when I entered the optimized parameter values directly via the Parameter Editor. I raise this purely as a system auditing issue rather than to get into the topic of whether or not it should matter if you enter a parameter value to 6 significant digits: I want two tests with the same parameters to give the same results.

Following is a simple line of code necessary to do the rounding in-system to ensure that any parameters internally generated will give the same results as if those numbers were entered on the parameter entry page.

To explain the line:

1) Take Absolute value (log of -ve will fail)

2) Take log to base 10 to get order of magnitude

3) Subtract from 6 to figure out number of decimal places for rounding

4) Accept a minimum value of zero (numbers > 10^6 round to integer)

5) convert this result to an integer

6) use it to round the internally generated parameter value to the value it would have held had it been entered on the parameter editor page.

7) note this works for negative numbers too.

I know, it's obscure, but you never know whom it might help.

When you enter a floating / percent parameter value (convert % inputs into decimals i.e. 1% = 0.01), TBB does some rounding:

1) If the number is greater than 10^5, the value is rounded to the nearest integer. 123456.789 -> 123457

2) If less than 10^5 but greater than 10^-4, the number is rounded to 6 significant figures. 123.456789 -> 123.457

3) If less than 10^-4, then the number is rounded to 9 decimal places. 0.00000123456789 -> 0.000001235.

This matters if you use any approach that involves re-setting a parameter value within a test (such as when randomly generating parameter values as part of a genetic search optimization) AND you want to be able to reproduce the results by "manually" entering your parameter values in the system.

It was making me crazy that sometimes my optimized results would agree to the penny, sometimes to the pound, and sometimes (due to the butterfly effect) were quite different when I entered the optimized parameter values directly via the Parameter Editor. I raise this purely as a system auditing issue rather than to get into the topic of whether or not it should matter if you enter a parameter value to 6 significant digits: I want two tests with the same parameters to give the same results.

Following is a simple line of code necessary to do the rounding in-system to ensure that any parameters internally generated will give the same results as if those numbers were entered on the parameter entry page.

Code: Select all

```
generatedParameter = Round(generatedParameter, asInteger(Max(0, 6 - Log(Abs(generatedParameter ), 10))))
```

1) Take Absolute value (log of -ve will fail)

2) Take log to base 10 to get order of magnitude

3) Subtract from 6 to figure out number of decimal places for rounding

4) Accept a minimum value of zero (numbers > 10^6 round to integer)

5) convert this result to an integer

6) use it to round the internally generated parameter value to the value it would have held had it been entered on the parameter editor page.

7) note this works for negative numbers too.

I know, it's obscure, but you never know whom it might help.