2009/5/25 Andrés Domínguez
> 2009/5/24 Don Dailey :
> >
> > To be honest, I don't like the Bronstein clock.
>
> I disagree. I think Bronstein is the best time control
> system. Players have fixed time per move, plus a
> pool time that can be used at the moves you want.
Bronstein is illogical be
2009/5/24 Don Dailey :
>
> To be honest, I don't like the Bronstein clock.
I disagree. I think Bronstein is the best time control
system. Players have fixed time per move, plus a
pool time that can be used at the moves you want.
> I believe the most logical time control for games in general is wh
2009/5/24 Don Dailey :
>
>> Believe it or not, I had to do special coding to handle CGOS. my bot tried
>> to adapt to network lag. Because the average lag for CGOS is negative,
>> subtracting future network lag before allocating time is incorrect. The time
>> allocation math would plan to have no t
> Believe it or not, I had to do special coding to handle CGOS. my bot tried
> to adapt to network lag. Because the average lag for CGOS is negative,
> subtracting future network lag before allocating time is incorrect. The time
> allocation math would plan to have no time left at the end of the ga
On May 24, 2009, at 8:47 AM, Don Dailey wrote:
2009/5/24 Christian Nentwich
Jason,
I used this time management code on CGOS and for off-line test
tournaments so far. I cannot claim that I have made additional
efforts to model/address network lag in it, so I don't yet know what
else I ne
I also use a time management system based on assumed moves left.
Before applying my logic to compute time to play based on the reported
time left, I subtract out network lag
Net lag buffer = (moves left) * (mean net lag) + (confidence level) *
sqrt [(net lag variance) * (moves left)]
I us
2009/5/24 Christian Nentwich
> Jason,
>
> I used this time management code on CGOS and for off-line test tournaments
> so far. I cannot claim that I have made additional efforts to model/address
> network lag in it, so I don't yet know what else I need to do with KGS, etc.
> Perhaps a percentage
Jason,
I used this time management code on CGOS and for off-line test
tournaments so far. I cannot claim that I have made additional efforts
to model/address network lag in it, so I don't yet know what else I need
to do with KGS, etc. Perhaps a percentage applied to the result computed
by the
How have you tested your time management code? CGOS is very bad for
testing time management because it gives a gift of time on every move
(to compensate for assumed network lag)
I think you might be missing a factor of two in your computations.
Only half the moves in a game count against yo
Doh. And just because typing mathematics in a mail from handwritten
notes had to go wrong: the initial formula was time(current move) / x ^
(1 / n), not 1 / x ^ (1 / n), otherwise it obviously cannot be solved
for the time in the second step.
Christian
On 23/05/2009 21:26, Christian Nentwic
This time management business is quite interesting. I looked into this
in some detail a while ago and came up with something I think is
reasonable for 9x9. I'd love to hear what you all think about it.
My algorithm relies on two key parameters: the time left (which is
either reported by a se
10:38 AM
To: computer-go
Subject: Re: [computer-go] Time weighting in opening
On Sat, May 23, 2009 at 12:34 PM, Brian Sheppard wrote:
>My general impression (also based on experiences from chess):
>Distributing time rather balanced over the moves is a stable
>strategy.
I have found
On Sat, May 23, 2009 at 12:34 PM, Brian Sheppard wrote:
> >My general impression (also based on experiences from chess):
> >Distributing time rather balanced over the moves is a stable
> >strategy.
I have found in Chess that you also want to spend more time up front. Part,
but not all of the r
13 matches
Mail list logo
