Hello,
I have lurked for a while now on this list, and now that I finally
have a weak monte-carlo/UCT program (goanna) up on CGOS, I decided
that I should say hello. I am going to be spending some time on this
project in the next few months, hopefully learning something about
monte-carlo based tr
You can:
a) Guess your opponents next response, and assume they will make this
move. Fire off a search from the resultant position. If you guess
correctly, then you save X seconds. But if you only guess correctly p
% of the time, you expect to gain pX seconds of extra thinking time
per move.
b)
On 5/1/07, Chris Fant <[EMAIL PROTECTED]> wrote:
> You can:
>
> a) Guess your opponents next response, and assume they will make this
> move. Fire off a search from the resultant position. If you guess
> correctly, then you save X seconds. But if you only guess correctly p
> % of the time, you ex
Hi Chris,
Thanks for your response.
Don has stated a couple of times that option (A) worked better for
him. I chose option (B) without testing option (A) because I did not
want to have to decide how many seconds to use to guess the opponent
move before starting to think about my next move.
T
On 5/1/07, Joel Veness <[EMAIL PROTECTED]> wrote:
My intuition suggests that b) is the better approach, but I know that
a) works much better in computer chess.
Does anyone know why a works much better in computer chess? Does the
benefits of a correct guess (and thinking more deeply than the
Orego also uses option B. Because UCT eventually focuses search on
the most promising moves, it probably will spend most of its time on
a single move, effectively doing A without the need for extra
parameter settings.
Peter Drake
http://www.lclark.edu/~drake/
On May 1, 2007, at 4:51 AM,
Hi Joel,
I did a lot of testing and for me option A seems a little better. The
problem with just pondering the latest known position is that there is
very little tree under moves the program doesn't think the opponent will
play. It appears to be
good to get the full blown benefit of a correct pr
On Tue, 2007-05-01 at 07:51 -0400, Chris Fant wrote:
> > You can:
> >
> > a) Guess your opponents next response, and assume they will make this
> > move. Fire off a search from the resultant position. If you guess
> > correctly, then you save X seconds. But if you only guess correctly p
> > % of th
Like most of the UCT programs (I believe), Orego adds one tree node
per Monte Carlo run. At present, this node includes data from the run
that created it. Thus, after the first run, my tree looks like this:
ROOT: 1/1 wins
CHILD A: 1/1 wins
Ignoring the other children, I eventually do
> smaller for larger boards. The only part of our program that is not
> strictly ANSI C++ compliant is is_there_input(), ...
> ...
> return select(1,&read,&write,&except,&timeout);
> ...
> If you are interested on a Windows equivalent, I might be able to
> provide one.
Hi Alvaro,
I'm interested i
Hello,
I thought I might get some answers on this list.
I haven't been able to get attachments from the new format of the AGA
newsletter even though I am a member. I do get the nice pictures but
no attachments. I was wondering if anybody else had some problems. I
realize it might be a problem wi
On Tue, 2007-05-01 at 08:35 -0400, Álvaro Begué wrote:
> We also chose (b), but not for the reason Chris posted. In chess you
> typically don't do any initial search to guess what the opponent will
> do; you use the second move from the PV line in the previous search.
I don't know what you do, b
There are a lot of experts here on computer chess.The answer is that
method A is overwhelming favorite of chess programs and as far as I know
a better way to take advantage of the opponents time has not been found.
The branching factor in chess is more like 6 and with all the selectivty
being
On 5/1/07, Darren Cook <[EMAIL PROTECTED]> wrote:
> smaller for larger boards. The only part of our program that is not
> strictly ANSI C++ compliant is is_there_input(), ...
> ...
> return select(1,&read,&write,&except,&timeout);
> ...
> If you are interested on a Windows equivalent, I might be
> Don has stated a couple of times that option (A) worked better for
> him. I chose option (B) without testing option (A) because I did not
> want to have to decide how many seconds to use to guess the opponent
> move before starting to think about my next move.
There is no need to spend any ext
I also am a member and did not get the attachments this time
Cheers,
David
On 1, May 2007, at 5:56 PM, Myriam Abramson wrote:
Hello,
I thought I might get some answers on this list.
I haven't been able to get attachments from the new format of the AGA
newsletter even though I am a member.
Like most of the UCT programs (I believe), Orego adds one tree node per
Monte Carlo run. At present, this node includes data from the run that
created it. Thus, after the first run, my tree looks like this:
ROOT: 1/1 wins
CHILD A: 1/1 wins
Ignoring the other children, I eventually do another ru
Hi Don,
Thanks for all your comments.
I should have mentioned in my initial post that I have a bit of a
chess programming background - which means I know option A quite well.
I have implemented pondering with both the Winboard and UCI protocols,
so I am confident that I know what needs to be don
Hi Peter,
On 5/2/07, Peter Drake <[EMAIL PROTECTED]> wrote:
Orego also uses option B. Because UCT eventually focuses search on the most
promising moves, it probably will spend most of its time on a single move,
effectively doing A without the need for extra parameter settings.
Yes, this is one
Hi Chris,
Yes, I understand that deciding on zero seconds is an option. But
consider the following situation: Your engine makes a move very
quickly (perhaps it is a statically-recognized, large-group-saving
move or maybe your time management code demanded a fast move). Now
suppose your oppone
My theory on pondering is that it's not very productive to
use it to just jump start the next global search.
In my conceptual model for a playing program, there are a lot
of "facts" that in fact are nothing of the kind - they're assertions
that you are willing to assume are true. I'm thinking of
On Tue, 2007-05-01 at 07:45 -0700, Peter Drake wrote:
> Orego also uses option B. Because UCT eventually focuses search on the
> most promising moves, it probably will spend most of its time on a
> single move, effectively doing A without the need for extra parameter
> settings.
Is this your intu
22 matches
Mail list logo
