On Fri, 2006-12-29 at 15:28 +0100, Łukasz Lew wrote:
The handicaps are set up in a way that white passes between Black's
moves.
Ie. he gives one point to the black N-1 times.
This isn't elegant. The stones work out nicely as you say, but after
a
pass move the opponent has a right to pass
Sent: Friday, December 29, 2006 9:28 AM
To: [EMAIL PROTECTED]; computer-go
Subject: Re: [computer-go] Fw: Compensation for handicap plays?
I did some research and I would like to change my vote.
My criterion for perfect rules are elegance, simplicity and
consistency.
As You know I want
On 12/29/06, Łukasz Lew [EMAIL PROTECTED] wrote:
I did some research and I would like to change my vote.
My criterion for perfect rules are elegance, simplicity and consistency.
As You know I want unification of area and territory scoring.
So here is my proposal.
The unification needs that
This seems clean and reasonable to me. (Or you could just as easily have
the server do the adjustment and set Komi to 3.5; that would also be consistent
with TT rules). If my bot sees 2 black moves in a row, it can figure out it's
in a handicap game.
A bigger question to me is, how
However, I will probably maintain the current scheduling
algorithm which
will make the larger mismatches fairly rare though not impossible.
This
will be good because it means we will still prefer non-handicap games,
and
I'm guessing that the vast majority of games will not be be large
hendicap
My plan was to simply use the same scheduling algorithm I currently
use. I would take the weaker base player and see if handicap
versions of himself more closely matches the ELO rating needed to
give an even game.
I assume the same method of an updated engine connecting with a new
login still
Okay. Don's later post does indicate that he intends to compensate
for the stones. So, in the interest of being 100% clear: is this
compensation included in the komi value that is sent to the client?
Weston
On 12/29/06, Weston Markham [EMAIL PROTECTED] wrote:
Am I correct in inferring that
I'm considering this proposal to rate handicaps separately, still
haven't decided but it's appealing.
My plan was to simply use the same scheduling algorithm I currently
use. I would take the weaker base player and see if handicap
versions of himself more closely matches the ELO rating needed to
I agree with you. Weston's post convinced me that the program should
know
in advance what the handicap is to be and thus sending consecutive
genmove
commands is not really correct technically speaking.
I don't like implied compensation, but apparently it is popular and KGS
does it. However,
Don Dailey wrote:
I'll take a final poll - speak now or forever hold your peace!
Should we:
1. Give white N-1 stones at end of game. (where N = handicap)
2. Give white N stones at end of game. (N = handicap)
3. Give white N stones except handicap 1 case.
4. Not worry about giving
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 28, 2006, at 10:28 , Rémi Coulom wrote:
Don Dailey wrote:
I'll take a final poll - speak now or forever hold your peace!
Should we:
1. Give white N-1 stones at end of game. (where N = handicap)
2. Give white N stones at end of
Markus Enzenberger wrote:
would it make sense to treat players with handicap
as completely different players? For example, GNU
Go giving one handicap stone would be a different
player and get a rating independent of GNU Go in
an even game?
I like that !! It would give very valuable
sorry, i just realized how out of context that was.
in response to X is 50kyu, Y is 300kyu, etc.
30kyu is a good bottom end. the bottom has to be
somewhere, and 30kyu humans are easily beaten by
most anything stronger than random play. more than
39 levels is asking quite a bit of the ranking
On 12/28/06, Urban Hafner [EMAIL PROTECTED] wrote:
(...)
Should we:
1. Give white N-1 stones at end of game. (where N = handicap)
2. Give white N stones at end of game. (N = handicap)
3. Give white N stones except handicap 1 case.
4. Not worry about giving white anything but
There are 3 gtp commands for handling this:
fixed_handicap
place_free_handicap
set_free_handicap
You are arguing that fixed_handicap, even though it's quite
explicit, is the wrong one to use in this situation?
set_free_handicap would also work - the server just specifies
the points and
There are 3 gtp commands for handling this:
fixed_handicap
place_free_handicap
set_free_handicap
You are arguing that fixed_handicap, even though it's quite
explicit, is the wrong one to use in this situation?
set_free_handicap would also work - the server just specifies
the points and
On 12/28/06, Don Dailey [EMAIL PROTECTED] wrote:
Just to be precise: KGS does option 2 if you select chinese rules, and
it also does option 1 when you select AGA rules.
And to be more precise, here is how it might work:
Handicap
0- komi is 7.5 and either player plays
To be honest, it seems very ugly to me but it seems to be what the
majority
like.
Apparently KGS handles it this way, the program just has to magically
know what the compensation is. But that's true of any handicap system,
the program has to have the correct understanding.
I think we had this
Here's John Tromp's reply: he does not specify compensation for handicap stones
- but leaves wiggle room for the players to choose such komi as they wish.
- Forwarded Message
From: John Tromp [EMAIL PROTECTED]
To: terry mcintyre [EMAIL PROTECTED]
Sent: Saturday, December 23, 2006
On Wed, 2006-12-27 at 19:16 -0500, Don Dailey wrote:
This is a mess. I'll need to make a decision soon as I'm already
testing the 19x19 server - getting some baseline data so that I
can then estimate the proper handicap assignments.
I don't know if this will be an issue for many
20 matches
Mail list logo
