I created the project javago in SourceForge.
(http://sourceforge.net/projects/javago)
I uploaded a bunch of base game classes, gtp, sgf,
gametrees, etc. And a full set of tests (around 200
tests right now).
The most interesting thing, the MC stuff is still not
uploaded. :-D (neither data
- the winners of last Sundays tournament on KGS. My report is at
http://www.weddslist.com/kgs/past/27/index.html. I expect people will
soon report the many misprints in it, as usual :)
Nick
--
Nick Wedd[EMAIL PROTECTED]
___
computer-go
I don't have specific information, but I worked on GGP with that group for
the last two years, and I think I can probably get in touch with them. I'll
see what they're up to and get back to you.
-Nick
On 6/3/07, Peter Drake [EMAIL PROTECTED] wrote:
I don't know, but I'd like to try it on the
On Tue, 2007-06-05 at 10:23 -0700, Peter Drake wrote:
While there is a bias in theory, I suspect that you are right that it
is not significant in practice if you maintain a list of vacant points
(as Orego now does), because almost all vacant points are legal.
In any case, switching to your
On 6/5/07, Peter Drake [EMAIL PROTECTED] wrote:
On a multithreaded program like Orego (running on a multicore machine), it
moves the nontrivial random number generation out of the synchronized part
of the program and into the threads.
I'm surprised to hear this. Do you have a single random
But if you are taking the vacant points out it is probably not
too biased as you say.
But what I do is pretty fast. Always choose a random point but
keep shrinking the list. When a point is occupied move it out
of the way so it's never selected again. You have to do some
simple bookeeping -
Oddly, there doesn't seem to be much effect on speed whether I use a
single random number generator (i.e., instance of java.util.Random)
or one for each thread.
Peter Drake
http://www.lclark.edu/~drake/
On Jun 5, 2007, at 11:59 AM, Jason House wrote:
On 6/5/07, Peter Drake [EMAIL
On Tue, 2007-06-05 at 12:28 -0700, Peter Drake wrote:
Don't maintain the list of legal moves -- maintain the list of vacant
points (almost all of which are legal). When it's time to pick a move,
pick a random point in the list and iterate through checking each move
for legality. As soon as you
On Tue, 2007-06-05 at 15:58 -0400, Don Dailey wrote:
You might improve the bias by shuffling on the fly, perhaps when you
find a legal move in the un-occupied point section of the list you
could
do a swap with the first move and a random move. I'm wondering if
the
biased ordering of the
On Tue, 2007-06-05 at 13:12 -0700, Peter Drake wrote:
So I'm only temporarily maintaining a list of illegal but unoccupied
points - this list gets discarded as soon as a legal move is
tried.
Does that mean you have to regenerate the list every move?
I keep the list of un-occupied points -
On Jun 5, 2007, at 12:58 PM, Don Dailey wrote:
On Tue, 2007-06-05 at 12:28 -0700, Peter Drake wrote:
Don't maintain the list of legal moves -- maintain the list of vacant
points (almost all of which are legal). When it's time to pick a
move,
pick a random point in the list and iterate
I have a request for the programmers of the weaker than 1800 programs
on the 19x19 CGOS (eg. ControlBoy, Explorer, Dog, AverageLib):
Please run your program overnight (PDT) once in a while to allow
for more precise ratings below 1800.
Thanks,
Christoph (myCtest)
-ansi -Wall -pedantic
Why not add -Werror so gcc rejects to compile code with warnings ?
Regards
Martin
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
13 matches
Mail list logo
