I always imagined that the reddit/HN/Digg algorithms (if you can call it that) went something like this:
1) submit article
2) attach Unix timestamp
3) increment/decrement each timestamp by a fixed time interval of Unix seconds for each upvote/downvote
With this scheme, there is one operation (add a positive or negative increment). Eventually each article will naturally decay as time moves on. You can adjust the size of the increment to be weighted more closer to the actual submission time and have the increment decay to an average to accelerate "hotter" postings to the top if you don't like linear increments.
The overall idea is to project an article (in Unix timestamp) into the future by the number of upvotes; this timestamp is merely a ranking "key". The front page articles would have a Unix timestamp of one or two days into the future depending on how many votes. This would naturally place currently submitted articles somewhere a few pages back.
It more or less mimics the same thing (doesn't it?).
Comments
I always imagined that the reddit/HN/Digg algorithms (if you can call it that) went something like this:
1) submit article
2) attach Unix timestamp
3) increment/decrement each timestamp by a fixed time interval of Unix seconds for each upvote/downvote
With this scheme, there is one operation (add a positive or negative increment). Eventually each article will naturally decay as time moves on. You can adjust the size of the increment to be weighted more closer to the actual submission time and have the increment decay to an average to accelerate "hotter" postings to the top if you don't like linear increments.
The overall idea is to project an article (in Unix timestamp) into the future by the number of upvotes; this timestamp is merely a ranking "key". The front page articles would have a Unix timestamp of one or two days into the future depending on how many votes. This would naturally place currently submitted articles somewhere a few pages back.
It more or less mimics the same thing (doesn't it?).