doubts about volatility computation about glicko2js HOT 3 CLOSED

Hi,
Mark Glickman was kind enough to analyze the issue.
In short, the default tau value (0.5) is too high for your particular set of match results. If you expect such situations where a high rank player looses many matches against a much lower ranked player, you should initialize the ranking manager with a lower value for tau :

var ranking = new glicko2.Glicko2({
            tau : 0.2,
            rating : 1500,
            rd : 350,
            vol : 0.06
        }),

Here is the explanation of Professor Glickman :

[...]
I confirmed the computation you sent. It turns out that the new version of the algorithm does indeed produce the correct values according to the optimality criterion used to derive the algorithm. The old version may not be finding the correct optimum.

The main issue here is that having a 1700 player lose 30+ times to a 1000 player is so unlikely (under the assumed system constants), the algorithm cannot make sense of such a situation and produces a strange-looking result. If in any application this sort of result is possible to happen, then the easiest fix is to set the system constant tau to a small value. The value tau governs how much the volatilities can change. Instead of using tau=0.5, using tau=0.2 gives much more reasonable behavior.
[...]

So my conclusion in examining this issue is that tau=0.5 will work well in general (and will require only a modest trigger to increase the RDs after game results), but if one may expect extremely improbable results in any given application one should use a smaller tau (such as tau=0.2).

Thank you for raising this issue. It allowed me to better understand the role of tau in the algorithm.

from glicko2js.

Hi,
Thanks for this detailed bug report.
This is very strange indeed. The author of the Glicko2 algorithm changed the procedure for computing the volatility, I followed the last version, the spreadsheet uses the old one.
I will contact Mark Glickman, the author of Glicko, for more information on this strange behaviour.

I've added the possibility to choose the algorithm as an option in the last commit (I have not updated the npm package).
You can call the old procedure it in your script like this :

var glicko2 = require('glicko2'),
    ranking = new glicko2.Glicko2({
            tau : 0.5,
            rating : 1500,
            rd : 350,
            vol : 0.06,
            volatility_algorithm : 'oldprocedure'
        }),
    Mary = ranking.makePlayer(1700, 30, 0.06),
    Bob = ranking.makePlayer(1000, 30, 0.06),
    matches = [],
    num = 10,
    i;

for (i = 0; i < num; i += 1) {
    matches.push([Mary, Bob, 0]);
}
ranking.updateRatings(matches);

To call the new procedure, replace 'oldprocedure' by 'newprocedure'.

from glicko2js.

Thanks!
as a follow-up, upon checking a bit more the excel version I was able to find "jumps" in that one too (where adding one more unlikely win suddenly greatly increases the volatility), but they were less pathological (say from 0.06 to 0.3). In any case, both methods should give the same result but apparently don't, so I'm curious to hear what Professor Glickman can say about this.

from glicko2js.