Surely system C (is that what we’re calling what we have?) but with the cosmetic display of system B is intuitive (except for 1 being bigger than 2) and you can just hide the decimal display by using the ± etc as above
The code converts rating to rank with decimals. If you’re 2.0-2.3333 or something you’re 2k+, if you’re 2.3333 to 2.6666 you’re 2k, and if you’re 2.666 to 2.9999 you’re 2k- ?
Or the way where 1 point something gets rounded down to 2 (which will make more sense once the decimals aren’t shown) which I guess is the actual current display.
Perhaps I should have said it like @pokk97 said: in System A, the [2k] range would coincide with decimal ranks 2.0k-2.9999k, and 3.1k is fairly close to 2.9999k.
I’d say all of this topic is about cosmetics. These system are all just different ways to present ratings in a (hopefully) clear and meaningful way to human go players.
In any system, 2k+ would mean ratings in the stronger 1/3 section of the [2k] rating range, 2k would mean ratings in the middle 1/3 section of the [2k] rating range, and 2k- would mean ratings in the weaker 1/3 section of the [2k] rating range.
In system A (not C) the corresponding decimal rank ranges would be like you say.
In system B the corresponding decimal rank ranges would be like 1.5001-1.8333, 1.8333-2.1666 and 2.1666-2.4999
In systems C and D the corresponding decimal rank ranges would be like 1.0001-1.3333, 1.3333-1.6666 and 1.6666-2.0.
But when decimal ranks are never exposed in the User Interface, I don’t think it matters whether the programmer picks system A, B, C or D to implement the 2k+,2k,2k- presentation. The programmer may not even use any of those systems and use a more sophisticated system instead. As long as it works, it works.
I should really reread this again and take notes to make sure I know what the differences are
I suppose if it turns out that the cosmetics happen to cause, more often than not, a player to thing there’s an incorrect handicap being given, if there’s some rounding involved, then probably the cosmetic solution is problematic.
So anything that rounds away from zero, like rounding up Dan ranks while rounding down kyu ranks (presumably the same would be done on either side) might lead one to think an extra stone should be given sometimes?
That’s kind of what you were saying with D before was it?
I think that’s partly because our handicap assignment system is too complicated.
For example, if you are a new “2k” at 1.9k, you’ll get an even game with anyone from about 0.9k to 2.9k. So you occasionally get an even game with a “1k” and almost always get an even game with a “3k”. Just by looking at the displayed ranks, though, you’d expect 1 stone of difference. And we don’t display enough digits anywhere to predict the handicap reliably.
My opinion is that if we used the (integer) difference between displayed ranks it would be just about as accurate and far easier to understand.
I’m not a big fan of the additional classes. I think in the kyu range +/- (or up/down arrows) are not as clear as decimals.
The distance between 19.4k and 20k is closer than the distance between 19.1k and 20k. And even though I’m not sure that’s intuitiv for someone with discalculus, I don’t think it’s more intuitive, that 3k+ means stronger than 3k and not weaker. Some might wonder, whether 3k+ is closer to 2k- or 4k-.
This seems to have been made utterly complicated when it is a seemingly straightforward thing?
Rank is a hierarchy, you improve and progress through it.
Each new rank is a new milestone to be reach, and as such as you move through the kyu ranks, you have not reached the milestone of the next rank until you get to it, eg once you hit 10.0 you are a 10 kyu. When you improve a tenth or the way to the next rating, you have not reached the next milestone yet and are still at your previous rating, so as one would progress from just turning 10kyu, to a marginal improvement to 9.9 kyu, to 9.5kyu, and so on… Until you have reached the next milestone of 9.0 you haven’t hit 9 kyu.
It’s the exact same way we discuss age, you aren’t 1 until you have lived a year, then you are 1.1 years old, up to 1.9 years old but you are still 1 until you reach 2.0 years old (43.9 years of age hasn’t reached 44 yet)
Since their is a progression, there is a direction and if we are speaking in integers you haven’t reached the next step until you are there yet.
Indeed, it would work to code system B as a flooring-based approach made to look like rounding.
Code-wise this would imply to add 0.4 to kyu ranks and substract 0.5 to dan ranks (where system A adds 0.9 to kyu ranks and keeps dan ranks as they are), relative to current values.
But IMO up/down arrows ↑↓ are clearer than +/-:
While 2k+ could be interpreted as tending towards 3k OR tending towards 1k, arrows could simply be read as direction (up or down) as in the Dan/Kyu scale:
…
2d↑
2d
2d↓
1d↑
1d
1d↓
1k↑
1k
1k↓
2k↑
2k
2k↓
…
I wouldn’t be surprised if an up arrow was misinterpreted as “number goes up” (2 tending towards 3), or as “number went up recently” (2 now, but recently 1), or as “rank went up recently” (2k now, but recently 3k). But it could be negligible, I don’t know.
I feel the reverse (+ to be more clear).
The up sign is confusing, it can be you are stocking to go to 1d or you are elevating you from 1d
Although you could say the same from a + sign the adding property which is not included in the arrow is underlining better the accumulation over a rank already acquired.
It’s funny how feeling vary, trust me at least that i am not trolling anyway. I explain my pov not to claim it’s the right one.
I think when it’s about ranks, or things you might want to communicate with others regularly, it helps to have a single system. If there’s 6 displays of rankings (A-D mentioned above and the ± and up down arrows), as an extreme example, imagine the confusion of trying to communicate anything about it to someone else, another player, a moderator and so on.
