The round robin format is much better for something like this. I cannot even imagine trying to pair games using this system.
Don On Thu, Jul 12, 2012 at 10:43 AM, Nick Wedd <[email protected]> wrote: > On 12/07/2012 15:22, Don Dailey wrote: > >> I assumed with the log or square root function that the winner would get >> this number of points and the loser would lose the same amount. And >> it should be centered around a komi value in my opinion - so that if >> komi is 5.5 you consider a score of 7.5 to be worth 2 points or sqrt(2). >> >> I like your function just as well or even better. I'm not fussy about >> the exact function used, just the arbitrary cap which has no logic at >> all. Even if they had no cap it would be better. >> >> You say it's not clear what they are trying to achieve, but I think that >> was explained. The explanation left me reeling because it had to do >> with strong programs crushing weak programs and not getting overly >> rewarded for playing a weak opponent. >> > > You can blame me for that, not Łukasz. He suggested the cutoff at > +-50, it seemed reasonable to me, and I tried to explain why. > > > But this system basically does >> reward the program that plays the most weak opponents >> > > This is irrelevant - the event is a round robin. > > Nick > > > and I think it's >> really flawed in general. >> > > > > >> The real point of this is to impose a more western attitude to the game, >> trying to "crush" your opponent - pick off every possible stone you >> can, etc. In this system it's possible to lose most of your games >> and still win the tournament because a small loss is hardly better than >> a small win. With any of these alternative scoring systems that >> situation is greatly improved. >> >> I did think of one interesting format. Suppose that you use the >> performance ratings of the programs in the tournament to decide the >> winner, but you count each stone as a separate game? In 9x9 you have >> 81 games, so the score can be 81 - 0, or anything in between (I >> strongly suggest centering this based on Komi.) A score of 81-0 is >> impressive, but if the program is really weak it's performance rating >> is going to be very low (not to mention the fact that beating it by this >> score won't help its performance rating.) This has some of the >> same flaws but it would still be fun. If you lose by a small margin >> it's not much worse the winning by a small margin. >> >> Don >> >> >> >> On Thu, Jul 12, 2012 at 9:53 AM, Álvaro Begué <[email protected] >> <mailto:[email protected]**>> wrote: >> >> We are dealing with a quantity (the score difference) which can be >> positive or negative, so neither square root nor log are very natural >> functions to use. >> >> If you want diminishing returns, here's a better way to do it: Give >> each player 1/(1+exp(-K*score)) points. As K goes to infinity this >> converges to the usual loss=0, draw=1/2, win=1. As K goes to 0 it >> becomes linear. Also the sum of points awarded to both players is 1, >> which is kind of a nice property to maintain. >> >> However, it is unclear what exactly they are trying to achieve, so I >> can't really suggest a particular function to use. >> >> >> On Thu, Jul 12, 2012 at 9:41 AM, Don Dailey <[email protected] >> <mailto:[email protected]>> wrote: >> > Like you I agree that they should not not use this at all. >> However, >> > given that this is what they want to do I would argue that using >> using the >> > square root function (or something like it) is really what they >> want. If >> > they believe 150 is no better than 50, but that it's suddenly >> linear below >> > 50, what sense does that make? It goes from being linear to >> being >> > nothing. So using the log of the score, or the square root, >> anything >> > like that, is a huge win and gives them the basic behavior they >> really want >> > without having an arbitrary cap. >> > >> > And by the way, the square root is not just as arbitrary as >> capping - >> > unless you define arbitrary as anything you might do (which in a >> sense it >> > is.) So maybe arbitrary is not the right word here. What we >> are looking >> > for is something that is a more logical means to an ends - and >> the cap is >> > not nearly as good as the log or the square root. >> > >> > Don >> > >> > >> > >> > On Thu, Jul 12, 2012 at 9:25 AM, Álvaro Begué >> <[email protected] <mailto:[email protected]**>> >> >> > wrote: >> >> >> >> The square root is just as arbitrary as capping at 50. The only >> >> function I really like is capping at 0.5. >> >> >> >> Álvaro. >> >> >> >> >> >> On Thu, Jul 12, 2012 at 9:16 AM, Don Dailey >> <[email protected] <mailto:[email protected]>> wrote: >> >> > Truncating to [-50 .. 50] seems rather arbitrary to me too. >> There >> >> > should >> >> > either be no truncation at all, or if the concept is to not >> "over >> >> > reward" >> >> > big wins it should be replaced by a function such as the >> square root of >> >> > the >> >> > score. In this way you get progressively less credit for >> bigger and >> >> > bigger wins. >> >> > >> >> > Don >> >> > >> >> > >> >> > On Thu, Jul 12, 2012 at 5:48 AM, Rémi Coulom >> <[email protected] <mailto:[email protected]>> >> >> >> > wrote: >> >> >> >> >> >> Why truncate to [-50..50] ? >> >> >> >> >> >> On 10 juil. 2012, at 22:20, Łukasz Lew wrote: >> >> >> >> >> >> > Fellow Go enthusiasts, >> >> >> > I would like you invite you to: >> >> >> > >> >> >> > Kaś Cup - a peculiar computer Go tournament. >> >> >> > >> >> >> > There will be prize pool of total 100$, yay! >> >> >> > It will take place on 5th of August on KGS. >> >> >> > >> >> >> > The peculiarity will come from the scoring method. >> >> >> > While this will be a Round Robin, the score for each game >> won't be >> >> >> > +-1 >> >> >> > point, >> >> >> > but the exact result of the game truncated to the [-50 .. 50] >> >> >> > interval. >> >> >> > >> >> >> > One last rule is that participants may not use more than 4 >> cores of >> >> >> > CPU >> >> >> > power. >> >> >> > >> >> >> > Nick kindly agreed to organize and look after the >> tournament for >> >> >> > which >> >> >> > I am grateful. >> >> >> > Also he is in charge of choosing a ruleset and time settings. >> >> >> > >> >> >> > Thank you and let us know if you will participate. >> >> >> > Łukasz >> ______________________________**_________________ >> Computer-go mailing list >> [email protected] >> http://dvandva.org/cgi-bin/**mailman/listinfo/computer-go<http://dvandva.org/cgi-bin/mailman/listinfo/computer-go> >> >> > > -- > Nick Wedd > [email protected] > > > > ______________________________**_________________ > Computer-go mailing list > [email protected] > http://dvandva.org/cgi-bin/**mailman/listinfo/computer-go<http://dvandva.org/cgi-bin/mailman/listinfo/computer-go> >
_______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
