Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handicap adjustment should consider "proper handicap" #7

Open
ghost opened this issue Sep 23, 2020 · 4 comments
Open

Handicap adjustment should consider "proper handicap" #7

ghost opened this issue Sep 23, 2020 · 4 comments

Comments

@ghost
Copy link

ghost commented Sep 23, 2020

There's a page about "proper handicap" over at Sensei's Library. At first I didn't get it, but now I think this could affect OGS's ranking system.

Komi is worth half a stone

Consider this: Black moves first and is therefore one stone ahead, then white follows and closes the gap, but without komi, that's unfair, because the game is always switching between "black one stone ahead" and "equal number of stones". To make this more fair, white starts off with points worth half a stone (about 7 points). This way the game switches between "white half a stone ahead" and "black half a stone ahead". To make the game fair, whoever is half a stone behind is allowed to move next.

Handicap 1 is actually handicap 0.5, handicap 2 is 1.5 and so on

On OGS a game with "handicap 1" means the two players are one rank apart and the stronger player takes white with almost no komi (0.5). White gives an additional stone per additional rank difference. This does not fit the 1 rank = 1 stone rule, as the default komi (6.5 on OGS) is only worth half a stone.

This should be considered in get_handicap_adjustment()

The players ranks are adjusted in handicap games when estimating win rates, but now the weaker player is considered x ranks stronger due to handicap, when it actually should only be considered x - 0.5 ranks stronger. Therefore black's strength and win rate is always overestimated and a loss affects black's ranking more than it should, while the opposite is true for white. I don't know how much it would contribute to improving the rating system, but to me it seems like changing get_handicap_adjustment() to reflect this issue could help reduce the volatility of ratings.

Additionally one could think of changing the handicap system OGS is using, but that should maybe be discussed separately.

@ghost ghost changed the title Handicap adustment should consider "proper komi" Handicap adjustment should consider "proper handicap" Sep 24, 2020
anoek added a commit that referenced this issue Jan 12, 2021
@anoek
Copy link
Member

anoek commented Jan 14, 2021

FYI I've been playing with this, honestly it doesn't seem to make that much of a difference, so much so that I'm not sure if it's better or worse, it's kind of lost in the noise. I'll continue running it in tests though and if something meaningful emerges I'll run with it.

@ghost
Copy link
Author

ghost commented Jan 14, 2021

You might be right with that diagnosis.

Anyway I took a peek at that commit above and it seems to me that the handicap is only adjusted if it is == 1, but I think it should always be adjusted if it is >= 1.

So this

    if HALF_STONE_HANDICAP:
        return rank_to_rating(rating_to_rank(rating) + (0.5 if handicap == 1 else handicap)) - rating
    return rank_to_rating(rating_to_rank(rating) + handicap) - rating

should imo be changed to

    if HALF_STONE_HANDICAP:
        return rank_to_rating(rating_to_rank(rating) + (handicap + 0.5 if handicap > 0 else 0)) - rating
    return rank_to_rating(rating_to_rank(rating) + handicap) - rating

@ghost
Copy link
Author

ghost commented Jan 14, 2021

Now I'm unsure if it should be +0.5 or -0.5

@anoek
Copy link
Member

anoek commented Jan 14, 2021

oh probably -0.5, might change things. I had a version that applied for > 0 as well, I'll try it again with -0.5

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant