Histogram of all official 3x3 results

[Michael Stocker]

I created a histogram of all 3x3 results (up to 30s): [x-axis: time in hundredth, y-axis number of times it has occured as an official result]

But there is a suspicious gap here. I first thought it was a mistake in my code. But I could not find a problem with it.
I then double checked it with some direct calculation using a query I got:

SELECT v/100, count(*) FROM
(SELECT value1 as v FROM Results WHERE eventid = "333" AND value1 > 1499 AND value1 < 1600
UNION ALL
SELECT value2 as v FROM Results WHERE eventid = "333" AND value2 > 1499AND value2 < 1600
UNION ALL
SELECT value3 as v FROM Results WHERE eventid = "333" AND value3 > 1499AND value3 < 1600
UNION ALL
SELECT value4 as v FROM Results WHERE eventid = "333" AND value4 > 1499AND value4 < 1600
UNION ALL
SELECT value5 as v FROM Results WHERE eventid = "333" AND value5 > 1499AND value5 < 1600
)as t
GROUP BY v

Is this maybe some rounding thing of stackmat timers?

 

[qwr]

Can you link the original db you used? and can you produce a table for each hundredth of a second between 1500 and 1600 centiseconds? It may very well be a bias of stackmat timers.

 

[Michael Stocker]

I used the results export of the wca https://www.worldcubeassociation.org/export/results

And I double check it for the smaller interval with this

https://statistics.worldcubeassociation.org/database-query?sqlQuery=SELECT+v%2F100%2C+count%28*%29+FROM%0A%28SELECT+value1+as+v+FROM+Results+WHERE+eventid+%3D+%22333%22+AND+value1+%3E+1499+AND+value1+%3C+1600%0AUNION+ALL%0ASELECT+value2+as+v+FROM+Results+WHERE+eventid+%3D+%22333%22+AND+value2+%3E+1499+AND+value2+%3C+1600%0AUNION+ALL%0ASELECT+value3+as+v+FROM+Results+WHERE+eventid+%3D+%22333%22+AND+value3+%3E+1499+AND+value3+%3C+1600%0AUNION+ALL%0ASELECT+value4+as+v+FROM+Results+WHERE+eventid+%3D+%22333%22+AND+value4+%3E+1499+AND+value4+%3C+1600%0AUNION+ALL%0ASELECT+value5+as+v+FROM+Results+WHERE+eventid+%3D+%22333%22+AND+value5+%3E+1499+AND+value5+%3C+1600%0A%29as+t%0AGROUP+BY+v

 

[Spencer131]

It does seem very strange that there are 2 clusters. What query and data did you use to get the first histogram?

 

[DGCubes]

Cool histogram! Gen 2 stackmat timers only ran at 60Hz even though they showed 2 decimal places, which made some times impossible (but this is no longer the case on newer generations). That's likely the cause of the gaps here - the gaps should thin over time since we've moved away from Gen 2.

 

[Michael Stocker]

That would explain it. It would also explain why the gap seems to be smaller at lower times. I guess most time below 10 seconds are more recent than the slower times.
Splitting it to times before 1.1.2019 and after, we can see that this fault is more or less gone.

 

[DGCubes]

So cool! Great explanation for the smaller gap for faster solves too. Will be interesting to see how this graph looks years down the line as the percentage of Gen 2 solves gets smaller and smaller.

 

[ProStar]

Very cool!