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???

[AristosQueue (NI)]

Round To Nearest takes the .5 point and rounds it up OR down whichever takes it to the nearest even integer. This produces much better rounding with lower error over time than the rounding that people learn in school (i.e. that 5 always goes up). The reason there is no such "simple rounding" function in LabVIEW is that there pretty much isn't any demand for that kind of inaccuracy in actual programming.

In short, we complicate so simple a thing because that simple thing is generally a bug to be fixed.

[altenbach]

Why do you say that "round half up" is "proper"??? What does that even mean?

I agree with Aristos that this should not change. "Round half to even" is the default rounding for the IEEE floating point standard and is thus most universally accepted. You don't want LabVIEW to give different results than any other software package out there!

There are also limitations due to the internal floating point representation, where many simple decimal fractions cannot be exactly represented. You might get some surprises when rounding to fewer digits (e.g. using a display format of %.1f). For example, 0.45 (DBL) rounds to 0.5 (closest decimal value is 0.450000000000000011) and 0.15 (DBL) round to 0.1 (closest decimal value is 0.149999999999999994), seemingly breaking the round to even rule unless you carefully inspect all internal digits.

[Intaris]

What Altenbach says, imperfect representation introduces its own errors.  As I understand it (I did some reading int he appropriate IEEE standard once when I was really bored) the error over the entire numeric range is minimised by using the "round to nbext even" approach, which is the reason why it's implemented in that way.  It is the most "right" solution numerically.

Also detailed a little bit HERE.

End of story.

[SteenSchmidt]

Getting the proper error distribution from rounding depends on your specific dataset. Thus in reality you should select rounding algorithm from your knowledge of your entire dataset. 'Round to even' is one of the best choices for a uniform and continuous dataset (e.g. random real numbers), but any dataset bias away from this should make you bias your rounding algorithm as well. It should be noted that IEEE 754 (for instance) isn't a uniform dataset, so rounding that can lead to surprising results.

Just to be perfectly clear: the aim of your rounding algorithm is to get a uniform error distribution over your entire dataset.

/Steen

[tst]

A few years ago I ran into the same situation (http://forums.openg.org/index.php?showtopic=690) and the good reason for it was that there was an end user who inputs values in manually and expects to see the regular rounding they learned in school.

In practice, I haven't had another case since then where I needed something like this, so I'm a bit split on this. I do think it makes sense to have it, but I haven't seen much of a real need for it.

Also, note that your code will probably not function as you want with negative numbers (assuming you want to round those). If I remember correctly, the code I posted where I linked to doesn't handle that either.

[MimiKLM]

Guys,

The replies of all four of you are talking about equal rounding error distribution, which is a statistical thing; from the statistic point of view your augmentation is allowed.

However, I think about something which is NOT connected to any statistical analysis. I'm talking about singular number here.

Why in LV I can't have the simple intuitive rounding function, the 'most natural' rounding. If you go shopping what rounding type you are applying/expecting at the counter?

Why I can have it in excel, but not in LV?

I do know that my solution for sure will be rejected if I round 3.5 and 4.5 to the same number of 4. Regardless all statistical argumentation.

Why to complicate obvious things?

[RavensFan]

LabVIEW does have the "bankers rounding" function.  That is according to Wikipedia, rounding half to even.

[MimiKLM]

I'm sorry RavensFan, I've made mistake. I should write 'intuitive' instead of banking.

I've corrected my comment above

[Intaris]

Obvious things are sometimes wrong.

Correct things are sometimes complicated.

[SteenSchmidt]

@MimiKLM: Look, if you need to round a certain way, just implement that then. But if you are asking why LabVIEW natively does it some other way, you have to accept the reason.

Sometimes an algorithm must go "add 1 to the input number except when the input number is divisable by 167 in which case add 3". But one's rare need for such an odd incrementation algorithm probably won't get you far in changing the ++ operator in C++ to do exactly that for instance. Yours is such a case.

LabVIEW is a programming language which more often controls machinery or processes large chunks of data, more often than it is used to build the front end of a cash register. In that regard the wisest choice of rounding algorithm is as symmetric as possible (or your robot would always shoot a bit too long or too short, when you step to some position). In fact, "asymmetric rounding" in machinery is often the reason behind the need for recalibration (periodic or continously) when that machinery performs stepwise actions (superposition). The cause is that almost all mechanical positioning systems (gears or pistons for instance) "rounds down" due to stick or backdrag, so they end up slightly short of the target. Thus precision positioning machinery is made such that its passive motion components attempt to compensate by having half the action parts round up (move a bit too far, for instance a piston with slight overpressure at idle) and half the action parts round down (for instance same type of piston with a slight underpressure at idle). The same way you compensate for vibration in rotating parts by having a counter-rotating flywheel or balance shaft. For you control-guys and -girls out there, I'm talking only about the mechanical build-up, before we start to add active regulation mind you 😉

Kids are tought round-half-up in school as that is one of the simpler rounding algorithms, and because that is most often used with cash money, not because it's the "right" algorithm. It only seems the most intuitive if you never progressed any further in education (or experience), and thus were never forced to consider the implications.

/Steen