On the other end, PG could just add a line at the end of the home page to show one post randomly selected from the new articles. This way we could all contribute to the selection of new articles, instead of only relying on those brave souls who regularly wade through the "new" page.
Why HN Should Use Randomized Algorithms
11–20 of 41 posts
Re: Why HN Should Use Randomized Algorithms
#12I think it's a great idea that solves an actual problem and it would probably help smooth out voting rings that slip past the detector. However, that would probably mean HN couldn't optimize or cache the front page. On the other hand, this is a feature for logged-in users only, so it might be feasible.
This way the page can be cached.
Re: Why HN Should Use Randomized Algorithms
#13Re: Why HN Should Use Randomized Algorithms
#14 86 points by luu 58 days ago | flag | 41 commentsRe: Why HN Should Use Randomized Algorithms
#15Giving a randomness to the whole sorting of the articles could have a "noisy" effect on users who update the home page often. On the other end, PG could just add a line at the end of the home page to show one post randomly selected from the new articles. This way we could all contribute to the selection of new articles, instead of only relying on those brave souls who regularly wade through the "new" page.
Yes, but not much. Provided the amount of noise is small enough, the order of articles on the front page may change a bit, but the articles themselves won't change much. I don't know much about the typical distribution of scores of articles on the front page at any given moment, but I suspect even the order of most of the page probably won't be affected.
Think about it this way: pushing an article that's already high up on the home page up or down a little in ranking won't push it off the front page. It's only the bottom of the page (and the top of page 2) that would even be materially affected.
Re: Why HN Should Use Randomized Algorithms
#16It's a good idea, though I wonder if there is a better way to do this without randomness.[1] I mean it's just an exploitation vs exploration problem. You want to maximize the number of articles the average user will upvote (essentially avoiding wasting our time.) You want to use the time and number of votes to predict the probability that a user will upvote it. But you also want to do "experiments" to find even bette…
http://www.bayesianwitch.com/blog/2013/why_hn_shouldnt_use_r...
Re: Why HN Should Use Randomized Algorithms
#17Re: Why HN Should Use Randomized Algorithms
#18I think it's a great idea that solves an actual problem and it would probably help smooth out voting rings that slip past the detector. However, that would probably mean HN couldn't optimize or cache the front page. On the other hand, this is a feature for logged-in users only, so it might be feasible.
It could also be done via client side JS. Load the first 2 pages of results with the true scores and then use JS to add the randomness factor. This way the page can be cached.
Re: Why HN Should Use Randomized Algorithms
#19I think it's a great idea that solves an actual problem and it would probably help smooth out voting rings that slip past the detector. However, that would probably mean HN couldn't optimize or cache the front page. On the other hand, this is a feature for logged-in users only, so it might be feasible.
Out of nowhere, anywhere from 6 to 14 seconds to load the front page (or any other HN page) when logged into that account.
Re: Why HN Should Use Randomized Algorithms
#20I think it's a great idea that solves an actual problem and it would probably help smooth out voting rings that slip past the detector. However, that would probably mean HN couldn't optimize or cache the front page. On the other hand, this is a feature for logged-in users only, so it might be feasible.