Enhanced dislike calculation algorithm

[Tali64]

Extension or Userscript?

Extension

Request or suggest a new feature!

In light of #1063 and #1066 (former resolved by Anarios, latter closed by author), I have been thinking about potential ways we could improve the way Return YouTube Dislike extrapolates dislikes. After brainstorming several expressions, here's what I came up with:

Let a be the public like count, b the private dislike count, c the extension user like count, and d the extension user dislike count. a/(a + b) is the actual like-to-dislike ratio. a/(a + d) will always be an overestimate of the actual ratio since d will always be less than or equal to b; c/(c + d) will always be less than or equal to a/(a + d). Thus, (a/(a + d) + c/(c + d))/2 should provide a better approximation of the like-to-dislike ratio in the majority of cases.

To recover the dislike count, we find the reciprocal of the like-to-dislike ratio, multiply by a, and subtract a (in other words, a * 1/(a/(a + b)) - a = a * (a + b)/a - a = a + b - a = b); applying the same steps to the estimated like-to-dislike ratio yields the formula 2a/(a/(a + d) + c/(c + d)) - a. This formula has an average error comparable to if not better than the current method in most cases: https://www.desmos.com/calculator/xoiubmt6ln; most importantly, it's far more accurate when a/(a + d) and c/(c + d) are far off from each other, since it takes both into account to produce a better approximation of the dislike count overall.

Ways to implement this!

No response

Can you work on this?

• Yes
• No

Will you be available for follow-up questions to help developers implement this?

Yes

[Tali64]

After some consideration, the current algorithm is fine and probably doesn't need changing; however, I do have another suggestion that I will make a separate request for - linearly interpolating the dislike count between data updates. The API could be modified to add last updated date parameters and the last average rate of change per minute the dislike count increased by, so that when the updated is requested from the API, it can be approximated more accurately between stat updates rather than just standing still until the statistics are updated serverside.