Ideas for sorting the results

[homerours]

Hi,
I just discovered and started using your plugin recently, and I like it a lot. Thank you very much for it!
You wrote in the README that "The [score computation] parameters here still need to be tuned, so please let me know if you find some magical parameters!". So here I am with my two cents. I spent some time on similar problems for a personal project, so I have some (hopefully helpful!) takeaways to share:

• You define frecency of a result that has been accessed at times $t_i$ as

$$F = \sum_i f(t-t_i)$$

where $f$ is a piecewise constant function defined by some access_thresholds. This forces to store all access times, and has complexity proportional to their number. I would recommend taking $f$ as an exponential $f(x) = e^{-\alpha x}$ so that you would only have to remember the time of last access and the value of $F$ at that time to compute $F$ at later times. You get constant time/space complexity for computing the frecency, and having $f$ with exponential decay is not too restrictive (and probably not too far from your current $f$).

• Then, when computing the score by summing the frecency $F$ to the proximity bonus $P$, I would recommend using something like $\log(F) + P$ instead of $F+P$. The motivation goes as follows. Roughly speaking $F$ is proportional to the number of accesses. Suppose that we have two results A1 and A2 which have been accessed 10 and 20 times respectively. If scores are defined as $F+P$, A1 would need to get a "relative" proximity bonus proportional to $20-10=10$ in order to be ranked before A2. This may sounds fair, A2 has been accessed twice as much as A1, so is a priori two times more likely to be accessed in the future. However, if we consider now two other results B1 and B2, which have been respectively accessed 100 and 200 times, B1 would need to have a "relative" proximity bonus proportional to 100 in order to be ranked before B2. This does not sound fair: B2 is here also twice more likely to be accessed than B1, but B1 has to get a "proximity delta" of 10 times the one A1 needed to be ranked before A2. Even with a very large proximity bonus, B1 will provably never ever be ranked before B2.
  Taking the log allows to solve this issue since $\log(20) - \log(10) = \log(200) - \log(100)$. I wrote some more related details here if your are interested.

I do not know much Rust, so I have not implemented/tried it in your plugin. But I would recommend giving a try, it made a big difference for my use case :)
All the best and thanks again.

[Saghen]

The exponential trick and the log are both really clever, thank you! I'll convert this into an issue so I can track it