Hacker News Reader

Comment by gpm | Hacker News Reader

Sorry for the rant, but I hate this obsession with chopping off digits people have.

25.68% ± 40.42 is not the same as 26% ± 40. If I am later trying to make a model to get the best estimate of <stat> by looking at a bunch of other people's measurements I will get a more accurate answer if more digits are contained.

When someone presents a state like 26% without the ± it's at least excusable, since it's avoiding making people think that 25.68% was short hand for 26.68% ± (0.005 ± 0.005)%, but when we're including the ± there is no good reason to chop off digits.

I do like the comment someone else has about reporting this as a range instead of with a ± sign, i.e. "-14.74 to 66.1 percent".

View on HN

This is a pet peeve of mine as well; significant figures can be handy, but fundamentally they originated as a quick and dirty method of keeping track of uncertainty that was quite handy when doing calculations by hand, but is more or less obsolete today any time you have an actual quantitative uncertainty bound.

Sure, it's still convenient when writing things out in text to not continue adding digits far beyond the uncertainty of your value, but even so there is nothing "conservative" or in any way accurate about chopping off a bunch of digits (however imprecise) and replacing them with zeros. This is especially clear if we consider that we generally only ever consider sig figs in base 10, but in any computational context that number is definitely not stored in base 10.

If you really need the precision, you should use the raw data. Why is 25.68 precise enough and not 25.682393. Especially, since it is given in the abstract, and not in some kind of in detail supplement.

> If I am later trying to make a model to get the best estimate of <stat> by looking at a bunch of other people's measurements I will get a more accurate answer if more digits are contained.

But that is exactly what I doubt: that level of accuracy is not there. You predict a number that has been observed for a sample size of 35. If you now add sample #36, you will almost certainly get a different number. The (round-about, I did not calculate it in any way) two floating point digits are not accurate, they are chance. And a model predicting 25.72 would be no better than one predicting 25.94.

I think the intuition here is that if your error bars on the measurement are +- 40%, how can your accuracy on the error bars themselves be 4 significant figures, i.e. +-0.1%?

>how can your accuracy on the error bars themselves be 4 significant figures

They aren't, but that's still the number you got. Chopping off the digits means you're slightly changing the result. It's like Tic Tac and their "0g of sugar" label, despite being 90% sugar.

But the "0g of sugar" in TicTac is something totally different. The difference between 25.68 and 26 is 2% of the total number (while the error of 40 is almost 160%). The difference between 0.01 and 0 is 100%.

My point is that it allows these kinds of things to happen. What's the point in making the number less accurate? In probability the difference between 0.999 vs 1.0 is enormous and these kinds of things can happen when you just floor numbers.

I think the point is that given the size of the error bars, that much precision is not an accurate representation of the confidence we should have in the result. 25.68% might be the observed change, but it's not one we should have much confidence of being accurate, not to four significant figures. Glibly put, it's false precision.

No-one I've seen arguing for fewer significant digits says that a probability of 0.999 should be rounded to 1. Nor do they say it's ok to round 0.5 to 0.

There's no false precision. There's a whopping +/- 40% error bar! What can be said is that 26% is at least less precise on average. You've added a completely arbitrary 0.32 because of some obsession with decimals.

I think we're in agreement that the 0.32 is false precision?

No, because there's an error bar. Why is 0.32 the false precision and not some other random number.

I think if you're doing this level of nit-picking, it's far more likely that somewhere along the line a scientist used a 32 bit floating point in their analysis and blew the precision out of the water before the number even got to you.

Did you just divide by zero?

He divided by 0.1, otherwise he would never have gotten to 100%.

It’s probably not the number they got though; the STDDEV calculation or whatever error measure you choose will usually give you lots more decimal places. The decision was taken to round to 4 significant figures.

If you got 10 decimal places in your calculation, it would obviously be nonsense to give all of them.

Reply on news.ycombinator.com