Title.
https://join-lemmy.org/docs/contributors/07-ranking-algo.html is everything you need
To summarize it for people that don’t feel like clicking the link, it essentially takes the log of the post score and then divides it by an exponential function of the time since the post was published.
And this picture helps too: shows the decay in ranking scores for posts of different popularity (score) over time.
After a day or so, the curve flattens out. This probably explains why we keep seeing posts that are months old in “hot” - if not enough new material is being posted, after the first few pages of “hot”, posts that are 5 days old and 5 months old are essentially the same due to the exponential decay function that was chosen.
That page gives this equation:
Rank = ScaleFactor * log(Max(1, 3 + Score)) / (Time + 2)^Gravity
Score = Upvotes - Downvotes
Time = time since submission (in hours)
Gravity = Decay gravity, 1.8 is default
My guess is that the “gravity” parameter is the issue at the moment. Something is needed to make the decay less steep, so that really old posts aren’t making it up to the top of the feed.
There might be some way of tuning the gravity parameter dynamically based on how much content is being submitted, perhaps aiming for something like “the average age of the first 200 posts should be 10 days” (I made those numbers up, but the basic idea would be that the time decay should be steeper when lots of content is submitted and less steep when content is infrequent?)
So who can change the algorithm? Is it up to the admins of each instance (lemmy.world in my case) to change the numbers? There’s not a centralized formula that each instance refers to is there?
Damn. So comments are not included. Anything that has a crapton of comments yet is controversial won’t be shown despite being hot.
Very nice analysis.
Maybe you want a more neutral and stable metrics for a dynamic measure of the gravity? Otherwise you can flood Lemmy with new posts to bury something.
Maybe something related to the average number of active users over the past 30 days over the topics you are looking at, which is harder to alter. But regardless, the steepness is definitely an issue as it should change with the number of posts.
After all of this, I will amend my response to say that I think that there must be something going wrong with the algorithm. Consider these two consecutive posts on my “hot” feed:
The anti-vax nonsense from two years ago was appropriately downvoted to hell. The post right underneath it is one year old and has a post score of +13. Based on the equation above, the lower post must have a higher rank than the anti-vax post, as it should have both a higher numerator and a lower denominator.
Time for a review of the source code? Or am I missing something? Do other people see this phenomenon? No older, lower-scored post should be above a newer and higher-scored post in your feed, I think.
don’t worry, its already fixed. should be in the next release.
On my personal instance I’m running a build with that and its properly giving nice recent posts ( including the OP)
And the relevant source code
And this is a great thing about open source software
Want to know how something works? Want to know the implications of something, or whether it is artificially manipulated? You can go directly to the code.
How does the algorithm work for other software, and is it authentic and not manipulated for other gains? Nobody knows except them, and bad stuff can be hidden away.
Can someone who knows PL/pgSQL help parse this line:
return floor(10000*log(greatest(1,score+3)) / power(((EXTRACT(EPOCH FROM (timezone('utc',now()) - published))/3600) + 2), 1.8))::integer;
It seems to me that the issue might be that the function returns an integer. If the scaling factor is inadequately large, then floor() would return zero for tons of posts (any post where the equation inside floor() evaluates to less than one). All of those posts would have equivalent ranks. This could explain why we start seeing randomly sorted old posts after a certain score threshold. Maybe better not to round here or dramatically increase the scaling factor?
I’m not sure what the units of the post age would be in here, though. Probably hours based on the division by 3600? And is log() the natural log or base 10 by default?
In any case, something still must be going wrong. If I’m doing the math correctly, a post with a score of +25 should take approximately 203 hours (assuming log base 10) before it reaches a raw rank score of < 1 and gets floored to zero, joining all of the really old posts. So we should be seeing all posts from the last 8.5 days that had +25 scores before we see any of these really old posts… But that isn’t what’s happening.
Just curious, is this something that admins of individual instances could adjust for themselves? I could see some specialized instances being able to make use of a customized sorting algorithm for this.
If this is something that admins can adjust, does that impact anything with that content shared to or accessed from any federated instances?
