On Fri, 2006-12-29 at 15:49 -0500, Don Dailey wrote:
> 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 compen
Assuming that kgsGtp's way of compensating white for the handicap
stones is incompatible with CGOS's proposed handling, (in other words,
if it is the case that kgsGtp sends a komi value that does not include
this compensation, even though the final score will. Is this true?) I
would like to brief
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, C
On Fri, 2006-12-29 at 15:13 -0500, Weston Markham wrote:
> 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?
There is no implied compensation
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 t
using gen_move to place handicap stones seems unreasonable to me when there
is a command intended for that purpose. The point of GTP is to make it easy
to implement the protocol. Anything that either breaks programs that are
written to the specification (as in using gen_move instead of
free_plac
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
As someone who might write programs that will play on the server, I
would like to put my 2 cents in:
As long as the final score is simply the difference in the number of
intersections controlled by each of the players, adjusted by komi,
then I will be happy. Whatever compensation for the handica
>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
>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
>h
On Fri, 2006-12-29 at 12:53 -0500, [EMAIL PROTECTED] wrote:
> 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
On Fri, 2006-12-29 at 12:53 -0500, [EMAIL PROTECTED] wrote:
> 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 ou
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 l
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 *
Behalf Of Lukasz Lew
>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, simpli
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
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 *pass* costs one point.
And this is only modification
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
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 pl
>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
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 tel
> And your programs must be set up to "just understand this" if it
> matters.
> ...
> it will know where to put the
> stones initially,
I disagree with this portion. One of the handicap options has the
server explicitly tell the client where to put the handicap stones.
For the sanity of everyone,
On Thu, 2006-12-28 at 15:36 -0500, Don Dailey wrote:
>
> And to be more precise, here is how it might work:
>
> Handicap
>
> 0- komi is 7.5 and either player plays black.
> 1- komi is 0.5 and weaker player plays black.
> 2- komi is 0.5, weaker player g
>And to be more precise, here is how it might work:
>
> Handicap
>
> 0- komi is 7.5 and either player plays black.
> 1- komi is 0.5 and weaker player plays black.
> 2- komi is 0.5, weaker player gets black, white gets
>2 points.
> 3- komi is 0.5,
On Thu, 2006-12-28 at 16:32 +0100, nando wrote:
> 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
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
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
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 informat
>> 2. Give white N stones at end of game. (N = handicap)
I vote for 2.
But my reason is that 2 is the closest to some future international Go rules.
I.e it allows for smooth integration of area and territory scoring.
Łukasz
On 12/28/06, Urban Hafner <[EMAIL PROTECTED]> wrote:
-BEGIN
-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 game
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
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 pr
Actually, 1 program would have at most 10 entries if I allow
up to 9 handicap stones.
Unless I also rated each program's performance taking and giving
the handicap! But this seems foolish.
- Don
On Wed, 2006-12-27 at 20:58 -0500, Don Dailey wrote:
> This is definitely an interesting idea.
This is definitely an interesting idea.If I were to do something
like this
I think I would want to have separate display pages for each program,
otherwise
you might have 10-20 entries for a single program!
It would require quite a bit of reworking of the server.
Let me think about this a bit.
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?
Then there is no problem about how to shoehorn handicap into the ELO system.
It w
Don Dailey 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 the appropriate
handicap stones.
Opti
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 programs, but the
Monte Carlo programs will have to figure it co
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 4
38 matches
Mail list logo
