I really wish the analysis didn't cut off at exactly 10 numbers. Rerunning the query with higher LIMIT, I noticed the following:
- The very next two numbers are 100 and 0. While 100 is consistent with the article's explanations, 0 still placing high despite fixing the query warrants further investigation. A quick glance at returned headlines shows the problem of phantom zeroes is not, in fact, fixed.
- The query doesn't group decimals and integers together. 2.0 is at #17 with 10k hits, while 1.0 is at #26 with 5k hits. So not only is the "version number" explanation for top numbers wrong - the claim that earlier version numbers are more common than later version numbers is wrong too.
Comments
I really wish the analysis didn't cut off at exactly 10 numbers. Rerunning the query with higher LIMIT, I noticed the following:
- The very next two numbers are 100 and 0. While 100 is consistent with the article's explanations, 0 still placing high despite fixing the query warrants further investigation. A quick glance at returned headlines shows the problem of phantom zeroes is not, in fact, fixed.
- The query doesn't group decimals and integers together. 2.0 is at #17 with 10k hits, while 1.0 is at #26 with 5k hits. So not only is the "version number" explanation for top numbers wrong - the claim that earlier version numbers are more common than later version numbers is wrong too.
0 probably comes from things like "0 day (vulnerability)" and "0 deps".
Not from what I've seen. Still lots of 1.0's, 0.1's etc. counted as 0.