What does 68.458335 round to?

Factual Questions
41

I agree that generally, rounding as late as possible is best.

There are some places where intermediate rounding is valid (where, as you say, it can’t be helped), for example:

[ul]
[li]Calculating the total of a series of invoices that contain fractional components at the detail level - you don’t generally want fractions of pennies on separate invoices to add up to one whole penny on the monthly statement - so the rounding is performed at individual invoice level, even if the invoice totals themselves are not discretely stored in rounded form (and database purists often warn quite sternly against storing calculated values)[/li][/ul]

[ul]
[li]Calculating the number of packs of some consumable required to service multiple different jobs - you probably just need to round them all upwards to the nearest pack per job.[/li][/ul]

42

The third example is not rounded, it is still the calculated average. Round to even would resutl in 20.

This seems to be missing the point that if you have a calculated number with a zero in the next position after your rounding position, you are still rounding. The statement that you are not rounding at all is incorrect. The round up at 5 rule rounds five of the ten possible digits in the next position up and five of the ten possible digits in the next postion down. The round to even actually rounds down 55% to 45% so it is the one with the bias. It gets the 50% in does in the other method plus half of the fives.

43

OK, clearer example. Don’t average the numbers, just take the sum:

No rounding: 390
Round up : 400
Round to even: 390

“Round up on 5” always introduces an upward bias, given a normally distributed set of data. If you don’t believe it, write a quick script and see for yourself.

44

What are you rounding to in your example? Since your round up went from 390 to 400 it appears that you are rounding to the nearest 100. In that case, round to even rounds to 400 also. You round to the nearest even value at the level you are rounding to.

Again, the idea of a bias in the round up at .5 comes from the misunderstanding that rounding from 3.0 to 3 is rounding (assuming that the .0 was an actual value (significant digit). The better example is rounding to the nearest integer:

3.05 rounds to 3 with round up at .5 and with round to even
3.5 rounds to 4 with both
4.5 rounds to 5 with round up at .5 and rounds to 4 with round to even

45

I am rounding to tens.

46

Then both round up at .5 and round to even result in rounding 390 to 390. They only produce a different result if the digit after the one you are rounding to is a 5.

47

Note, the “round to even on 5” rule is only when there are only zeroes after the 5. The point of rounding it to add the minimum amount of error to your calculation. Rounding 68.5 to two digits should produce 68, but rounding 68.500000000001 to two digits should produce 69.

48

OP, how many digits are significant?

49

As others have said, you don’t round your numbers until you’re done with all the math. As such rounding is a matter of presentation, not math, and you should round to whatever number you feel gives the most accurate/useful representation of your results. It all depends on what the number is supposed to represent. For example, if you calculated “how many seconds do I need to reach the fire exit” you probably want to round up to 69 (or 70, or 100).

50

This is only true with a 50% probability if you’re doing stochastic rounding.

However, there is a 99% probability nobody here is.

51

No. Run some computer simulations of rounding 1000 random numbers if you don’t believe us.

Here’s another way to look at it: When you’re rounding you’re actually adding or subtracting a value to your original number so that the last digit becomes zero. If you’re doing this operation a lot, it’s better if the amount you’re adding or subtracting averages out over time so you don’t introduce a bias to your data.

Assume that you’re just rounding off one digit to keep it simple. And that your data is evenly distributed so that each different digit occurs 1/10 of the time in the least significant position. If you always round up on x.5, this is what happens:

x.0 → occurs 10% of the time, add 0.0

x.1 → occurs 10% of the time, subtract 0.1
x.2 → occurs 10% of the time, subtract 0.2
x.3 → occurs 10% of the time, subtract 0.3
x.4 → occurs 10% of the time, subtract 0.4

x.5 → occurs 10% of the time, add 0.5

x.6 → occurs 10% of the time, add 0.4
x.7 → occurs 10% of the time, add 0.3
x.8 → occurs 10% of the time, add 0.2
x.9 → occurs 10% of the time, add 0.1

Note that the 10% of the time you subtract 0.1 is balanced by the 10% of the time you add 0.1 … no bias is introduced. And the same is true for where you add and subtract 0.2, 0.3, and 0.4. Over a large number of samples, the rounding cancels out.

But 10% of the time you add 0.5 with nothing to balance it. That means over a large number of samples you’ll be bumping your data slightly higher on average.

If, on the other hand, you use the round to even rule you get this:

x.0 → occurs 10% of the time, add 0.0

x.1 → occurs 10% of the time, subtract 0.1
x.2 → occurs 10% of the time, subtract 0.2
x.3 → occurs 10% of the time, subtract 0.3
x.4 → occurs 10% of the time, subtract 0.4

even.5 → occurs 5% of the time, subtract 0.5
odd.5 → occurs 5% of the time, add 0.5

x.6 → occurs 10% of the time, add 0.4
x.7 → occurs 10% of the time, add 0.3
x.8 → occurs 10% of the time, add 0.2
x.9 → occurs 10% of the time, add 0.1

Now you’ll wind up adding 0.5 as often as you subtract 0.5 and the bias is eliminated. See?

52

The case I extracted is the only time the two methods give a different answer in the rounding. Both methods introduce an error of .5 in that case. There is no doubt that round to even generates a lower value over a large sample. What I’m not seeing is any reason that being .5 too low is any better than being .5 too high.

53

Because the “always round up” method always is .5 too high. The “round to even” method is .5 too high half the time, and .5 too low the other half of the time. So over a big data set it cancels out.

54

Depends on whether or not the digits you’re eliminating are significant. That does not necessarily follow the fact that they exist.

55

But if you are working with a large data set, you shouldn’t be rounding at the intermediate results. When you get to the end and round, there is only the only point where the error comes in - the final result - and it is a wash between the two methods.

56

Are you saying that you will only ever round anything once ever in your entire career? Because if you ever round more than once, you’ll end up with biases you’d prefer to avoid. It’s one thing to say “at the end of the calculation”, but when precisely is that? Every calculation is an intermediate step for some other calculation.

57

But there are plenty of practical instances where you do have to round at the intermediate result all the time. Like, say, accounting, where interest can come down to fractions of a cent, or parts may be priced down to an accuracy of a tenth of a cent per unit (or whatever), but you can only record/pay/etc. down to the cent. If you have a lot of these transactions where rounding must occur, the “fairest” way to do so is to round using the nearest-even rule. That rounded amount should, in the long run, give the closest value to the “true” value (if we had the ability to track each value with perfect precision.) Always round 5s up will, in the long run, be over than the “true” value.

This also comes up in a practical sense all the time for me when adding a long string of numbers in my head. Let’s say I don’t want to deal with the ones place. If I want to round it off fairly and get the closest ballpark figure to the unrounded value, round to even should produce the best result (or alternate rounding, or whatever scheme you want to use for counterweighting the bias) given a set of data that doesn’t bias, for whatever reason, toward or away from even.

58

Mine rounds to 11.

59

Only if she lets you finish.