Correcting round function / new correct round function

[MimiKLM]

Hi,

I'm bit afraid to post this idea, because it seems to be I could overlook something.

There is no function which do the proper rounding (with 5 a a last digit as a hard limit) as below:

If the last digit is 5 o greater round up, otherwise round down.

An example:

(to simplify I use only one digit after dot)

0.1 -> 0

0.4 -> 0

0.5 -> 1

0.9 -> 1

1.1 -> 1

1.4 -> 1

1.5 -> 2

1.9 -> 2

2.1 -> 2

etc.

Now to satisfy this function you have to do coding like this (just for numbers with one digit after the dot):

Why to complicate so simple thing???

[MimiKLM]

OK, 

Having read your posts I try to uderline the reasons for my idea. I'll try to be constructive in a positive way.

1. First of all there is no right or wrong methods of rounding. All of them are equally allowed, and users shall be able to freely choose them as they want. With awareness of course.

2. The name of that function is misleading as it is not a full description of how it works. It would be good if the user would be able to choose a method of tie-breaking, in the same way as is able to set for example comparison mode and limit inclusion in In range and Coerce VI. Round to nearest is a non-direct rounding method, and as the method of tie-breaking shall be listed and be ready to apply. According to wikipedia there are at least 8 methods of tie-breaking. BTW: first listed is the method I'm lobbying: round half up.

3. Why I don't want to prepare the code for myself? I did the code, but how big and not easy to quick read it is? Look, to do do basic and elementary thing as tie-breaking in rounding I had to develop quite big (in area) which is not easy to quick read. If you compare the size of the code and its readability to the value added by this code the ratio doesn't like good When someone would like to read the code fist of all the first questions in the mind would be why someone did it? wasn't something in the framework ready to use to make wanted tie-breaking method?. Now, if I'd like suddenly use different tie-breaking method, I'd need to develop another code to do the thing which in my opinion shall be a part of the build-in LV framework.

4. Tie-breaking methods are elementary thing in the computer arithmetic. As they, shall be part of the framework ready to use by a developer. Round half up shall be one of them.

I still upheld my idea (with small modifications described in this post) to have choice in method of tie-breaking, in result method of rounding.

I admit that maybe in the post and my comments above I created some ambiguity using words proper, intuitive and most natural. Sorry

[AristosQueue (NI)]

MimiKLM: Adding an option to choose how to do rounding would be "making a simple thing complicated" in many people's judgement. "I asked you to round... why is there an input asking me how to round? I learned this in school! Just do it, LabVIEW!" 🙂

For whatever method of rounding you want, create a subVI, document it, then use it in your code. But this is a case where the banker's rounding is what people need to be using the vast majority of the time for correct code. They use our function and they get better results and they don't even know it.

Even the argument that "well, you don't have to put them front and center, just make it a configuration that is settable on the node so it is available" doesn't really fly -- to me, I really can't justify spending R&D time generating all the other rounding strategies when it is relatively easy for the very few people who need them to generate them on their own.

[MimiKLM]

@AristisQueue:

(...)Adding an option to choose how to do rounding would be "making a simple thing complicated"(...)

No, it's about to make things right.

(...)in many people's judgement. "I asked you to round... why is there an input asking me how to round?(..)

Because is at least eight types of tie-breaking, every of which is allowable and explainable.

(...)I learned this in school! Just do it, LabVIEW!" :-)(...)

It is hard to believe that you learned banking rounding at school.

(...)For whatever method of rounding you want, create a subVI, document it, then use it in your code.(...)

I did it and I've explained above why in my opinion is not correct way. Developers have to focus to solve their task and no reinvent the wheel thinking about implementation of the roundings

(...)But this is a case where the banker's rounding is what people need to be using the vast majority of the time for correct code.(...)

I think the citation is needed to support this statement. What people need is what they request not that what they are suggested/forced to use.

They use our function and they get better results and they don't even know it.

Yes, I agree with this statement in 100%. They don't know how the result is computed. I can bet that majority of them would be surprised if someone would tell them how the default rounding really works. Better results? It depends how you define work better. I support the idea to always make aware decisions.

I really can't justify spending R&D time generating all the other rounding strategies when it is relatively easy for the very few people who need them to generate them on their own.

To make things right, to make a better product, to win/sustain position on the marker, to satisfy customer who always is right. I think is enough reasons. Moreover, it doesn't look like a big RD task.

[crossrulz]

"Moreoever, it doesn't look like a big RD task"

Until you count in the regression tests, peer reviews, system reviews, documentation, and who knows what else.  LabVIEW is a huge program.  And trust me, R&D has a lot more to work on than implement new rounding schemes that so few people really need.  Maybe Mr. Mercer has beaten into my head too much about how LabVIEW R&D is not a large group compared to the rest of NI and they have a direction they are working towards based on getting more people on board.  A new rounding scheme is not going to get new people on board.

NI is following the IEEE standard for floating point numbers.  That is good enough for me.  I have yet to run into a situation where this hurt me.

[Intaris]

In all honesty, someone who's programming with floating point numbers should be familiar with the inherent accuracy limitations of such and the effects it has on operations like rounding etc.  To think we should change an internationally standardised numerical approach to a "simpler" (but statistically biased) rounding scheme is ludicrous.

If you really want to have this function, program it yourself.

Take the number you want to round.  Subtract 0.4999999999999999999999999 from it and round up.  Done.

OR

Take the number you want to round.  Add 0.5 and round down.  Done.

[crossrulz]

Intaris, the "optional" rounding technique for IEEE for tie breaking is to round away from 0.  So you need to do some sign manipulation as well.  But that is by far the simplest way I could come up with.

RoundDown(ABS(x)+0.5)*Sign(x)

[Intaris]

What crossrulz said.

[MimiKLM]

Hi,

I've read once again all comments. Thanks for all of them.

Having read them calmly I'm still not convinced why I cannot have the half-up rounding as a part of the LV framework. 

All cons arguments you have presented (guys and girls), although some of them are really strong i.e.pointing that LV deals with the acquired data and it has to secure equal error distribution, or pointing that LV follows the standard, still clashes with the situation where in excel or C the round-half-up method is obvious, intuitive and easy accessible and no one discuss about it. (please have a look at attachments). Moreover, I did some questionnaires amongst my friends, colleagues from different business areas, customers, etc. and I can say that they first impression when I ask them how would they round 4.5 and how 3.5 and tell them that in both cases is 4, it was a surprise. 

Simplifying my particular case my test passes for even numbers and can fail for odd. It doesn't sound to be right approach.

I did not never suggested to change the standard. I want the half-round-up to be part of the LV framework; to have this as LV primitive on the same basis as I have bankers-rounding. So part of the comments referring to this I even thought about changing the standard I found inadequate. What I want is to have a freedom to use - as a part of the framework - half-up rounding in the same way as I can use it in i.e. in excel or in C.

The number of people I've spoken and their surprise suggest that having this type of rounding (half-up) is heavily used and widely expected. Even it has skew in the error distribution. Point is it is used to present final singular number not used in DSP.

The biggest advantage of the LV is easiness to code. IMO not having half-round-up primitive has a negative impact on the product from marketing and easiness point of view. And I don't think that LV should not have the half-up rounding only because the bankers rounding is secure from error distribution point of view, and LabVIEW is mainly for DSP.

Thanks for your input.

C:

Excel:

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.