How piefed currently ranks

I took a look into post.post_ranking which is an implementation of what has been described by Amir Salihefendic in 2015.

if post_date is None:  
    post_date = datetime.utcnow()  
if score is None:  
    score = 1  
order = math.log(max(abs(score), 1), 10)  
sign = 1 if score > 0 else -1 if score < 0 else 0  
seconds = self.epoch_seconds(post_date) - 1685766018  
return round(sign * order + seconds / 45000, 7)  

It looks esotheric to me.

1. The log(... score) is quickly explained by the recursion of higher visibility through higher scores. The higher the score, the more views and more votes. That's fine with me. A lot depends on the first votes, I can't argue with that. But why they picked the base of 10 is left unexplained.
2. The value 1685766018 refers to the unix date 2023-01-03T14:07:42. It looks like a magic/random date to me. However that date seems to be unimportant later on.
3. The divisor of 45000 seconds is equivalent to 12.5 hours, 1 half-day. Through dividing the post age by 12.5 hours the age is basically converted from seconds to half-days. Again, unexplained why 12.5 h.
4. In the end, we add up log(score, 10) + age in half days. I don't get why they add them up.

Say, we choose a different log base like 2 instead of 10. How would the age measurement need to be adapted in order to get the same post_ranking results? All I know is it is unimportant. We just have to adapt the 45000 s to be 13546 s.

If we'd change the magic date we would need to adapt the arbitrary 45000 seconds again. (Wouldn't change the rank, I suspect.)

Different approaches / statements

Here, something slightly different is claimed to be the reddit formula: Here, the sign decides if time is good or bad, not the log score.

score = log_10(|score|) + sign(score) * seconds / 45000  

Lobsters has this: (I removed a hotness-bonus, a comment score and several plus-ones.)

score = sign(score) * log(|score| + seconds / 81000)  

They call the 81000 s (22.5 hours) the "hotness window". That article features an interesting animation of three kinds of posts: viral hit, sleeper hit, steady performer.

Evan Miller explored the reddit formula and boiled it down to:

ln( score ) + factor * seconds  

Seeing similarites to Bayesian beta distribution in a poisson process, Miller concludes:

I realize that proposing any change to how Reddit works is one of the Internet’s most dangerous games, so I hesitate to beat the drum in favor of MillerSort™. But I believe that expected-utility theory and a simple random-reload model can help explain why the Reddit formula has been so effective in the past, and shine a light on aspects that might be improved. In particular, the Reddit formula should probably take into account the percent of votes that are positive, rather than just taking the difference between positive and negative votes.

By the way, the original seems to be over 12 years old: https://github.com/reddit-archive/reddit/commit/50d35de04b928836b7ee955c8a26f197e24ab01e That commit explains the diversity of where to put the sign function.

Say, I'd suggest a different, more physical ranking function. How would we test it? Does somebody have statistics?

Edit: Correction concerning the choice of the log base. Precision on point 4. Guess about having to change 45000 for a different magic date.
Edit 2: Moved my comment beneath a new headline in my OP.
Edit3: Added more different approaches / statements. Consistent naming.
Edit4: Fixed an error in Lobsters' function.

I'm traveling, so can't really provide much input. However there is some more discussion in a relevant codeberg issue: https://codeberg.org/rimu/pyfedi/issues/1115

I don't know anything about the decisions behind the code, but I can read the snippet you've pasted:

1. Every logarithm is the same curve! Different bases are simply scaled by a constant factor.

Since log_b(X) = log_a(X) / log_a(b) and log_a(b) is a constant

So you could choose a different base, but it would achieve the same thing as multiplying the result by a constant factor.

1. I would guess that this is the earliest date that a post can have in Piefed, so this subtraction puts the oldest posts near to zero. The date of the first commit in the Piefed repo is 28 Jul 2023, 02:07 UTC and the timestamp in the code is 03 Jun 2023, 04:20:18 UTC

2. The scaling of the age in seconds relative to the log-score sets the relationship between time and score. The choice here is that ~12.5hrs will be equivalent to a factor of 10 in score, so a post with 10 votes now will be ranked equal to a post with 100 votes from 12.5 hours ago. Or to put it another way, every 12.5 hours that go by, the rank will decrease by an order of magnitude relative to score.

3. We effectively want an exponential decay of the score. Since the score is already taken log10 and since log(a*b) = log(a) + log(b) we want to subtract the age (ie. ln( X.e^(-kt) ) = ln X - kt. Consider that age is now - timestamp so to subtract it we would be calculating - now + timestamp. Since we are only using these ranks to compare amongst eachother, the absolute value has no meaning, so the - now offset makes no difference and can be omitted. So you get log10(score) + timestamp as the rank calculation.

According to (4) we could also ommit 1685766018. But want it back in because the values get too large technically speaking, right?

In point (3) the legitimacy of the hotness-window of 12.5 hours strongly depends on the number of visits per day piefed has, doesn't it? It ignores how many visitors vote on posts across the site in that hour. Or how many could be made everytime the post is shown.

I don’t get what your concern is — Piefed is software, there’s nothing physical about it, so I don’t get what a “more physical ranking function” could mean? Setting aside the arbitrariness of the constants for a moment, if you shipped a change, what is the difference you would want see in the sorting of the posts? What is the end-user problem you are trying to solve?

Yes the constant time offset is unnecessary because it cancels out, but I imagine it made it easier to check the behaviour in the beginning.

The size of the window doesn't depend on traffic. An exponential decay curve has the same shape regardless of what initial value you start from.

By physical ranking I mean something users can grasp. If you 'drop' posts, maybe they should better be ranked like falling stones? If posts go 'viral', maybe they should better be ranked like infections? Reddit seems to have treated posts like random page walk phenomena, but not really. Then reddit "fixed" the ranking long after users started to call it the frontpage of the internet and piefed implements the "fix", not the original. Is this about taste?

1. The end-user problem of being exposed to some particular ranking function nobody can explain.
2. Piefed is not a closed system like reddit is. Maybe the ranking should take that into account.
3. Could ranking functions be configurable? Maybe that would avoid the doubts.

I feel like PieFed doesn't have enough content flowing through it for the effect of votes to fade away in 12.5 hours and perhaps 24 hours would be better.

Maybe it depends on how often people check for new content? If they're once-a-day people, 24h might be best. But people checking multiple times per day would see the same stuff too often. I think.

Honestly, the maths is a bit over my head. I just coded what that medium post said without fully understanding it.

That was me.

I must say it turned into an on- and off-project for me. Without any proper results. I mainly struggle with the nature of our metrics... I don't really agree with what's popular here... And the downvotes don't really mean the right thing, either. So my attempts turned into an impossible(?) quest for some way more elaborate "algorithm".

I'm still interested in improving our maths, though! And I heard several people asking for a " better" ranking, especially easier for beginners.