On Thu, 2006-12-28 at 11:53 +0100, alain Baeckeroot wrote:
> Le jeudi 28 décembre 2006 03:34, Don Dailey a écrit :
> > I'm having an interesting problem - my hope is to set
> > a random legal move making player (who doesn't fill
> > 1 point eyes) at ELO zero.
> Hmm maybe i misunderstand. It se
Le vendredi 29 décembre 2006 10:58, Aloril a écrit :
> On Thu, 2006-12-28 at 11:53 +0100, alain Baeckeroot wrote:
> > Le jeudi 28 décembre 2006 03:34, Don Dailey a écrit :
> > > I'm having an interesting problem - my hope is to set
> > > a random legal move making player (who doesn't fill
> > > 1 p
Is there a reason why we need to decide, in advance, which of these many
candidates should be the anchorman? If we set up a whole swathe of them,
surely a week of random even games answers many of these questions and gets
us well on our way to a stable basis for a 19x19 competition? Maybe after
th
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
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
>From what I know about rulesets, I actually prefer AGA. I believe it
was designed to have the same result for both area and territory
scoring. It has the pass costs one point rule. There's something
special about if white passes first because then the number of stones
places on the board are no
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 l
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
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
>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
>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
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
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
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
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
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 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
Don proposed creating multiple entities for programs playing at different
handicaps.
That seems to complicate things. Is it possible to factor handicaps into
elo-style ratings?
We might start with some assumptions that, for example, 100 elo points is
comparable to a one-stone handicap, test th
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
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
21 matches
Mail list logo
