I agree with you. I was trying to keep my example in line with the situation described in the OP where the rounding was done (for whatever reason) on the raw data.
But my main point remains unchanged. Whenever you’re rounding, if you always round 5’s up, you’re introducing a slight upward bias to your results.
Chronos said:
How likely is that, vs the person already rounded up? 13.47 just became 13.5 and you want to make it 14 instead of 13. Vs. the measurement being 13.56 and they truncated to 13.5?
ElvisL1ves said:
No, you fail to get the point. There are an odd number of digits that round. Zero doesn’t round. It is the demarcation point. Zeros truncate, because they are the even line. The next zero is the next even line. 5 is exactly the midpoint, which is why there are numerous systems for rounding that address different things to do with 5. For what you are saying to be true, zero also rounds up. It simultaneously rounds both directions.
Look at a metric ruler. Look at the hash marks on a centimeter. Which value is halfway between hash marks? 5. Right at the midpoint.
robby said:
Alex_Dubinsky said:
Accuracy is how close to the target. Precision is how tightly clustered the hits. Both rounding and truncating reduce precision - the clustering is opened up. But rounding tries to keep things as close to the same target point as possible. Truncating drifts off target.
robby said:
If my scale reading has the last digit at zero, and I’m trying to estimate the portion below, and I want to estimate at 1/4, that would be .25. But the value 13.25 would have too many significant digits, because 13 was the last certain value. Now, how do I pick that estimate value? Is it 13.2 or 13.3? Why? Again, I was estimating 1/4, which is actually a larger block than tenths. Certainly anything like 13.21 or 13.29 would be too many digits. But the best I can read is 13 and 1/4. How do you convert that to digital?
By the way, we’re not taught to round 5 down in Britain. Always up. (I’d never come across the “round to even” method until a couple of years ago, either.)
If your measuring device is delineated by unit increments (i.e. by “ones”) such that you can tell the measurement is between 13 and 14, but you are estimating the tenths digit, then there is no way that you can confidently state that the “correct” measurement is exactly 13 and 1/4 (i.e. 13.25). The best you can do is to estimate the tenths digit. If you are estimating the tenths digit (which is your uncertain digit), then the best you can do is to estimate whether the last digit is 2 or 3. If you are quite certain that the measurement you are trying to take really is 13.25, then this would actually be a case for rounding your measurement to even and recording 13.2. (Whereas if your best estimate was 13.75, you would record 13.8.)
If you’re estimating in 4 parts instead of 10, use a different base, where the number of parts is evenly divided by the base. Instead of choosing between 13.2 and 13.3, use binary: 1101.01 - two significant binary figures, exactly matching your ability to estimate the fractional part in fourths.
Wow… you just convinced me to blindly truncate.
robby said:
No, I’m saying that I cannot even estimate the tenths digit, the best I can do is estimate whether it is a half or a quarter unit between. I could record my data as
13 and 1/4
13 and 1/2
13 and 3/4
etc. That would eliminate the fuss over 13.25 vs 13.2 vs 13.3, at the cost of having to write fractions on the paper and then try to work the math with fractions instead of convenient decimals.
Had a real world example today. For various reasons, I was using a dial torque wrench with a scale that had delineations every 2 in-lbs in the 0 to 50 in-lb range. Because of the size of the dial and the spacing of the lines and the comparative size of the dial needle, the best I could do was estimate to the half an in-lb. So its 12 or 12.5 or 13. Not 12.2 - can’t see that finely.
Do I round the halfs to the nearest in-lb?
Arjuna34 said:
Yes, because that’s easier. :rolleyes: Why don’t I just record the data in Sanskrit while I’m at it. I know, I’ll just use tick marks.
By the way, yes I could record with 1/2, or 1/4 instead of decimals.
But here is the key: in base 10, 1/4 = 0.25 exactly. So writing 13.25 is precisely and exactly equivalent to 13 1/4.
Now as long as I am crunching the numbers, and I’m aware that I’m actually working with quarter units, not tenths, I can round the final value to whatever. But annotating the process so someone else can follow the work, I need to be clear.
Irishman, I believe you meant to say:
if one were to “round to even” keeping three significant digits, then the rounding would be like this:
3.390 is rounded to 3.39
3.393 is rounded to 3.39
3.387 is rounded to 3.39
3.383 is rounded to 3.38
In general round to even works like this (I am rounding to two significant digits). In the example below, the round to even rule only needs to be evoked for the three values that have a five in the last significant digit. (I put in bold the values where I needed to apply the “round to even” rule)
1.10 → 1.1
1.11 → 1.1
1.12 → 1.1
1.13 → 1.1
1.14 → 1.1
1.15 → 1.2
1.16 → 1.2
1.17 → 1.2
1.18 → 1.2
1.19 → 1.2
1.20 → 1.2
1.21 → 1.2
1.22 → 1.2
1.23 → 1.2
1.24 → 1.2
1.25 → 1.2
1.26 → 1.3
1.27 → 1.3
1.28 → 1.3
1.29 → 1.3
1.30 → 1.3
1.31 → 1.3
1.32 → 1.3
1.33 → 1.3
1.34 → 1.3
1.35 → 1.4
1.36 → 1.4
1.37 → 1.4
1.38 → 1.4
1.39 → 1.4
etc…
In my example above, I was only rounding and eliminating the last digit. If I were to eliminate more than one digit in my rounding, I consider all the digits when applying my rules
e.g. rounding to two digits after the decimal point, using “round to even”. the “round to even” rule only needs to be evoked for numbers that have, immediately following the last significant digit that I’m rounding to, a “5” followed by one or more zeroes. (I put in bold the values where I needed to apply the “round to even” rule)
1.3475 -> 1.35
1.3549 -> 1.35
1.3550 -> 1.36
1.3551 -> 1.36
1.3649 -> 1.36
1.3650 -> 1.36
1.3651 -> 1.37
1.3749 -> 1.37
1.3750 -> 1.38
1.3751 -> 1.38
(notice that, since I am using “round to even”, 1.3650 and 1.3651 round to different values, whereas 1.3750 and 1.3751 round to the same value)
Um, yeah, what he said I said. 
Yes! YES! Another advantage of my harebrained Binary Inches scheme.