NI TestStand Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
MimiKLM

The round-half-up type of tie-breaking shall be added as an option to the Round() function.

Status: Declined

I'm declining this idea due to lack of community support.

Now, if the number is exactly in between if two integers, TS rounding function uses bankers rounding method as a tie-breaking rule. Although bankers rounding tie-breaking rule generally secures equal statistical error distribution, in case of a need of rounding numbers with only one decimal place this tie-breaking rule produces output which could be different than - let say a natural - expectation. 
 
For example if we have a group of numbers like below:
 
{-2.0, -1.5, -1.0, -0.5, +0.0, +0.5, +1.0, +1.5, +2.0}
 
the basic expectation is to have them rounded like that (round-half-up):
 
{-2.0, -1.0, -1.0, +0.0, +0.0, +1.0, +1.0, +2.0, +2.0} 
 
However, using banker-rounding method instead of the rounding as above we see:
 
{-2.0, -2.0, -1.0, +0.0, +0.0, +0.0, +1.0, +2.0, +2.0}
 
I think round half up tie-breaking method option should be added for developers to use.
 
BTW: (the + and - signs and .0 notation are used just to keep the numbers to be easy to compare)
10 Comments
Norbert_B
Proven Zealot

Hm, not sure if my investigation is correct, but here the result:

Some languages (e.g. ANSI C) don't have any "round" functions as generic content. They do, however, often provide functions for dedicated rounding, e.g. "ceil" and "floor" (up or down, regardless of where the number is actually between the integers. So 1.2 with ceil rounds to 2).

All languages i have checked (LabVIEW and C#) provide a ROUND function which always uses banker-rounding.

 

So TestStand obviously simply follows common (and acknowledged) techniques for rounding. So why should TS suddenly provide a complete new technique/option?

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
crossrulz
Knight of NI

He wants this changed in LabVIEW as well:Correcting round function / new correct round function


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
MimiKLM
Active Participant

Yes,

 

Norbert, In my comment in LV thread mentioned by crossrulz I've checked the C and Excel and both of them offer half-up rounding.

 

K

 

 

Norbert_B
Proven Zealot

Kamil,

 

yes, maybe i missed that function in the investigation. What is the function name (ANSI C)?

And please read through the comments in the LV feedback. There are a lot of arguments why NOT to change the behavior.

 

This holds true of course for TS as well....

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
MimiKLM
Active Participant

Norbert,

 

Yes, I read the comments and understand what they are comming from; and I don't want to start another battle.

 

I didn't want to change rounding method, just to add one more tie-breaking rule to it.

 

My idea was regarding display the result on the report only. My customer expects numbers to be rounded and displayed like that:

2.5 ->3.0

3.5 ->4.0

4.5 ->5.0

5.6 ->6.0

not like that:

2.5 ->2.0

3.5 ->4.0

4.5 ->4.0

5.5 ->6.0

 

I thing the Round() funcion should deliver this functionality, rather than push developers to do some additional coding. 

 

 

Norbert_B
Proven Zealot

Essentially, your request should be for a complete new function. Modifying the existing round function is a no-go as it might break existing code. Similar adding parameters to the function is not possible/feasable.

Point is, that education in school teaches a rounding method which is statistically creating a lot of errors (it was only this one i learned back in school). I find your request "OK" as this learned method works different to the rounding we see in most (or even all) PROGRAMMING languages.

 

As a result, adding a new function or changing education are the two options to "solve" misunderstandings like this.

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
MimiKLM
Active Participant

Why a new function?

 

Can't another option - for example the parameter number 5 - be added?

 

List of options for Round funcetion now (TS2010SP1):

 

Number Round(Number number, Number option = 0)
This function rounds a number to an integer.
Parameter 1: The number to round.
Parameter 2: An optional parameter: how to round.
Pass 0 to round towards zero (the default).
Pass 1 to round away from zero.
Pass 2 to round towards positive infinity.
Pass 3 to round towards negative infinity.
Pass 4 to round to the nearest integer. If the number is exactly between two integers, rounds towards zero.
Returns: The rounded number.

 

BTW: description for option 4 in TS2010 is wrong: http://forums.ni.com/t5/NI-TestStand-Idea-Exchange/Bug-The-description-of-the-Round-function-is-inva...

warren_scott
Active Participant

link to an existing feature request for rounding:

being able to specify the decimal place to round to

http://forums.ni.com/t5/NI-TestStand-Idea-Exchange/Improved-Round-Function/idi-p/1729794

 

MimiKLM
Active Participant

@warren_scott

 

however you would still need to choose the tie-breaking rule for the last digit you want round to.

WireWeaver
Active Participant
Status changed to: Declined

I'm declining this idea due to lack of community support.

https://www.linkedin.com/in/trentweaver