Reverse Engineering II
Math brain teasers require computations to solve.
The formula discovered in "Reverse Engineering I" doesn't seem to apply exactly to many Braingle ratings once the number of voters gets larger. What is your best guess at the number of votes cast for each attribute of the following teasers prior to my vote, and how many of those were positive (fun/hard)? What do you think is the likely source of any "experimental error" between the formula and these reported ratings? (Notation is the same as in "Reverse Engineering I"). Multiple answers may be possible, because of the difficulty of determining how much of the reported data constitutes "experimental error."
Teaser M: (1.38, 1.20)[16] (+, ) > (1.53, 1.13)
Teaser N: (2.00, 2.22)[18] (+, ) > (2.11, 2.11)
Teaser O: (1.04, 2.82)[25] (, +) > (1.00, 2.87)
Teaser P: (2.13, 1.72)[44] (+, ) > (2.17, 1.68)
Answer
The formula from part I, for p positive votes out of v cast, was 4*p/v. I searched for fractions with denominators close to the reported number of voters and numerators that were multiples of 4 to try to find a good fit. Here are some of the best possibilities, with the resulting decimals reported below. Divide numerators by 4 to get the number of positive votes.
Teaser M: (16/12, 16/13)[16] (+, ) > (20/13, 16/14)
(1.33, 1.23)[16] (+, ) > (1.54, 1.14). It's hard to find a good match for this one. Another possibility is 20/15>24/16 (1.33>1.5) for the first rating, which is further off from the data, but doesn't require as many nonvoters.
Teaser N: (36/18, 40/18)[18] (+, ) > (40/19, 40/19)
(2.00, 2.22)[18] (+, ) > (2.11, 2.11) An exact match to the data.
Teaser O: (24/23, 68/24)[25] (, +) > (24/24, 72/25)
(1.04, 2.83)[25] (, +) > (1.00, 2.88) Pretty close.
Teaser P: (92/43, 72/42)[44] (+, ) > (96/44, 72/43)
(2.14, 1.71)[44] (+, ) > (2.18, 1.67) Off by .01 in every figure.
The above errors (particularly on Teaser M) would be hard to account for if the site were recomputing the ratings every time from p and v. We know that the site keeps track of v for each category, in order to qualify entries for the various lists. But the site may recalculate p every time from the previous (rounded) ranking, which could cause errors that could accumulate or cancel, depending on how unlucky/lucky you were about what order people voted in. This could account for the errors in the above data. If this is the problem, the best fix would be to keep a separate count of p for each ranking. A temporary fix would be to at least round p off to the nearest integer when deriving it from the previous ranking, which works up to around 200 votes or so.
Hide
Back to Top
 
