Topic: Rating system

einstein13 wrote:

WorldSavior wrote:

einstein13 wrote:

The simpliest idea for rank I know is to find proportion of win/all games. And since "rating" is providing decimals, the (almost) most precise equation for rank value would be:

ranking = 1000.0 * number_of_win_games / (number_of_win_games + number_of_lost_games)

This isn't a meaningful value.

Yes it is.

ranking = number_of_win_games / (number_of_win_games + number_of_lost_games)

is a "fraction of winnings". Multiplying it by a constant doesn't change the meaning.

No. If player A is better than player B, player A can still easily have a much lower winning percentage than player B. And number of draws is missing also.

Wanted to save the world, then I got widetracked

Top

Quote

Ok more precise questions for einstein:

What's the point of subtype? We are gonna put a special function for each score anyway

Two questions about your code:

def save(self):
        if self.id == None:
            # update previous records (if exist) of the same type & subtype to be inactive
            previous = Rating.objects.filter(active=True)
            previous = previous.filter(type=self.type)
            if self.subtype:
                previous = previous.filter(subtype=self.subtype)
            previous.update(active=False)
        super().save() # for Python 3.X
        super(Rating, self).save() # for Python 2.7
        return

• What's the point of having such function in the model? Never seen that

• Isn't the server always in python3?

float1 = models.FloatField(null=True, blank=True) # rating_deviation for Glicko
float2 = models.FloatField(null=True, blank=True) # volatility for Glicko
integer1 = models.IntegerField(null=True, blank=True) # number of win games for simple ladder
integer2 = models.IntegerField(null=True, blank=True) # number of lost games for simple ladder

Why not put everything in floats? If we are gonna use many score system, just transform to int when retrieving from db. 2 less lines

updated = models.DateTimeField(auto_now_add=True)
active = models.BooleanField(default=True)

Couldn't we rather have a new table with a season data (start date, end date, selected maps, players that particpated, their games, all the scores)? ==> i.e all that will be shown on the website to players It would also avoid this idea of active and inactive.

Top

Quote

einstein13 wrote:

• Isn't the server always in python3?

I am not sure what do you mean by "server". "Save" function exists in all django classes that are inheriting from models.Model.

Since the switch to the new server, the website is running on python version 3.6. It's a prerequisite for updating to any django version behind 1.11

Overriding the save()-method is a common task to apply some changes which are 'behind' of saving just some values into the database, e.g. format some strings or update other models with new values

Top

Quote

Why in my proposal is such thing? Because that is solving updating active value to False when new record appear. So that no other action is needed, but the history of the records is preserved.

I think I'll use that for current season or not anyway

But as it was suggested by WorldSavior, I have forgot about forfeits in my "simplest rank", so it needs 3 values instead of 2.

Yes we need 3 value for glicko2 anyway, we store volatility too

Will there be some kind of league? Say have a 'beginners' league and if a player reaches some points, he will moved up to the 'profi' league?

Yes of course! But not before stage 3, we need a lot of data to determine what are the limit of each leagues anyway

Top

Quote

teppo wrote:

Should the number of games contribute to ranking in some way? Should the ranking deteriorate over time? I would do both.

There are of course many fancy ways to do that. Placeholder suggestions below; feel free to invent something better.

Regarding "number of games": My simple approach could be that one needs at least 5 games for perfect score. If less games, the score is worse. Example: ranking := (numer_of_fresh_games/5) * 1000.0 * number_of_win_games / (number_of_win_games + number_of_lost_games)

Regarding "over time": Only 5 newest games contribute: number_of_fresh_games := sum (individual_new_game_freshness_value), where individual_new_game_freshness_value := 0.99 ** (number_of_months_since_game_was_played); and the freshness_values of 5 newest games are summed together (unless <5 games total, in which cases all are included).

The constant 5 is pretty small, meaning that it is in reach of many WL player. However, winning 5 games in a row by accident is unlikely enough. The number 5 is not well thought-of.

This suggestion has the funny side-effect that an old guy with lots of wins and recent inactivity can increase his score by losing a game (logic: rating might go down a bit, but ageing multiplier increases). I think this is okay: An old master is rewarded from providing that he is still around.

Once more: I am not saying that these are perfect ways to do it, but still, one single victory should not give perfect ranking forever.

Top

Quote