path: root/util
diff options
authorYorhel <>2014-09-15 14:14:26 +0200
committerYorhel <>2014-09-15 14:14:26 +0200
commitf24522cea27c66b5e217c168d1f780f22fa3ef63 (patch)
tree82f41a9297b479efa4b039ec94e08478f795f804 /util
parent5b5457e380d82567f59d1da92f8e0c81bc3100b9 (diff)
Change normalization factor in popularity ranking calculation
Suggested by Hinoe, quoting his reasoning: In popularity rankings, change the normalization from "sqrt(LowerVoteCount)" == "LowerVoteCount^0.5" to something that grows somewhat more slowly. Details: Natural logarithm itself (ln(LowerVoteCount+1)) is too slow; at the current VN count (15403), it returns 9.64; however, sqrt(15402) is just above 124.1, which I feel is already too high. After experimenting with the exponents a bit, I decided that the best point likely lies between 0.3, which returns a bit above 18.0, and 0.4, which returns a bit above 47.3. Thus, I suggest that the new function be LowerVoteCount^0.36788; the exponent is a 5-digit approximation of e^-1, just because it's a nice number in the specified area and works well, returning circa 34.7.
Diffstat (limited to 'util')
1 files changed, 1 insertions, 1 deletions
diff --git a/util/sql/func.sql b/util/sql/func.sql
index 6f51a6b2..3923ffb5 100644
--- a/util/sql/func.sql
+++ b/util/sql/func.sql
@@ -77,7 +77,7 @@ BEGIN
-- the following queries only update rows with popularity > 0, so make sure to reset all rows first
UPDATE vn SET c_popularity = NULL;
CREATE OR REPLACE TEMP VIEW tmp_pop1 (uid, vid, rank) AS
- SELECT v.uid, v.vid, sqrt(count(*))::real
+ SELECT v.uid, v.vid, count(*)::real ^ 0.36788
FROM votes v
JOIN votes v2 ON v.uid = v2.uid AND <
JOIN users u ON = v.uid AND NOT ign_votes