Re: [gnugo-devel] First Monte Carlo code ready for inclusion

2007-12-17 Thread Gunnar Farnebäck

Ben Lambrechts wrote:
 This are my conclusions after running several bots on CGOS:

* 1000 games per level
  o L1 :: 1698
  o L10 :: 1813
* 8000 games per level
  o L1 :: 1777
  o L10 :: 1938
* 10.000 games per level
  o L1 :: 1736
  o L10 :: 1827

 I don't know why the games at 10k games per level are weaker than the
 ones at 8k.
 Maybe it is because with the 10k-ones, I didn't rebuild gnugo with
 MAX_BOARD 9.

Most likely because your computer isn't fast enough to support 1
games per level at CGOS time settings, causing the time management to
regularly play at rather low levels. To see what's happening with the
level settings you should use the -d 0x400 option (DEBUG_TIME),
and make sure that stderr output appears somewhere you can read it.

I managed to reach 1986 (mgtest1) with level 10, 6000 games per level,
MAX_BOARD=19 and 1982 (mgtest2) with level 10, 7500 games per level,
MAX_BOARD=9. This discrepancy I attribute to CGOS rating uncertainty.

/Gunnar


___
gnugo-devel mailing list
gnugo-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gnugo-devel


Re: [gnugo-devel] First Monte Carlo code ready for inclusion

2007-12-11 Thread Gunnar Farnebäck

Ben Lambrechts wrote:

 What command line options are you using, more exactly?

 tcl.exe cgos3.tcl GnuCvs-1-MC * gnugoMC.exe --mode gtp --cache-size
 512 --chinese-rules --level 1 --capture-all-dead --monte-carlo
 tcl.exe cgos3.tcl GnuCvs-10-MC * gnugoMC.exe --mode gtp
 --cache-size 512 --chinese-rules --level 10 --capture-all-dead
 --monte-carlo

Ok, I sort of suspected that. The only practical difference between
these is that the first will start out at level 1 and play the first
few moves a little faster until it reaches level 10. This may be
slightly beneficial since the first few moves usually come from the
fuseki database anyway and the time saved can be better used later. On
the other hand it can't be very much time since move generation in the
fuseki is rather fast.

To reduce the span of levels that the time management is allowed to
use, you need to set --max-level (default 10) and/or --min-level
(default 0) options. The proper change above is to add --max-level 1
for GnuCvs-1-MC.

Additionally, on CGOS you should use --positional-superko to avoid
occasional losses for illegal moves. If you want debug output of the
level changes done by the time management, add -d0x400.

For maximum 9x9 strength you should also change MAX_BOARD in
engine/board.h to 9 and rebuild, then set --mc-games-per-level as high
as you can afford without the level dropping frequently due to
shortage of time.

/Gunnar


___
gnugo-devel mailing list
gnugo-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gnugo-devel


Re: [gnugo-devel] First Monte Carlo code ready for inclusion

2007-12-11 Thread Ben Lambrechts

So the correct commands are: (after I rebuild gnugo with modified board.h)

tcl.exe cgos3.tcl GnuCvs-1-MC * gnugoMC.exe --mode gtp --cache-size 
512 --chinese-rules _--max-level 1_ --capture-all-dead 
_--positional-superko_ --monte-carlo _--mc-games-per-level TOTEST_


and

tcl.exe cgos3.tcl GnuCvs-10-MC * gnugoMC.exe --mode gtp 
--cache-size 512 --chinese-rules --level 10 --capture-all-dead 
_--positional-superko_ --monte-carlo _--mc-games-per-level TOTEST_


Correct me if I am wrong please
Ben
 tcl.exe cgos3.tcl GnuCvs-1-MC * gnugoMC.exe --mode gtp 
--cache-size

 512 --chinese-rules --level 1 --capture-all-dead --monte-carlo
 tcl.exe cgos3.tcl GnuCvs-10-MC * gnugoMC.exe --mode gtp
 --cache-size 512 --chinese-rules --level 10 --capture-all-dead
 --monte-carlo

Ok, I sort of suspected that. The only practical difference between
these is that the first will start out at level 1 and play the first
few moves a little faster until it reaches level 10. This may be
slightly beneficial since the first few moves usually come from the
fuseki database anyway and the time saved can be better used later. On
the other hand it can't be very much time since move generation in the
fuseki is rather fast.

To reduce the span of levels that the time management is allowed to
use, you need to set --max-level (default 10) and/or --min-level
(default 0) options. The proper change above is to add --max-level 1
for GnuCvs-1-MC.

Additionally, on CGOS you should use --positional-superko to avoid
occasional losses for illegal moves. If you want debug output of the
level changes done by the time management, add -d0x400.

For maximum 9x9 strength you should also change MAX_BOARD in
engine/board.h to 9 and rebuild, then set --mc-games-per-level as high
as you can afford without the level dropping frequently due to
shortage of time.

/Gunnar


___
gnugo-devel mailing list
gnugo-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gnugo-devel




___
gnugo-devel mailing list
gnugo-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gnugo-devel


Re: [gnugo-devel] First Monte Carlo code ready for inclusion

2007-12-10 Thread Jens Yllman
If MC is implemented around GNU Go I thing that speed is more important then
the quality of the moves. That way low level is maybe better then high level.
MC is very dependent on speed.

Jens


 I've posted a new patch at http://trac.gnugo.org/gnugo/ticket/150 which
 contains a first version of my Monte Carlo code which should be in
 good enough shape to be added to CVS. It doesn't represent the full
 strength
 of the MonteGNU account on CGOS 9x9 but should at least suffice for a
 2000 rating there.

 To turn it on, use the option --monte-carlo. To set the number of
 Monte Carlo simulations per move, use the option --mc-games-per-level.
 That number (default 8000) is multiplied by the current level to give
 the actual number of simulations per move.

 Notice, however, that the --monte-carlo option will set the maximum
 allowed boardsize to 9x9. This is intentional because the code simply
 doesn't scale to larger boards. Of course anybody who is competent
 enough to modify the source code can change this, but I think that's
 a fair barrier.

 Please try it out.

 Now in CVS.
 I've put the CVS version on CGOS this weekend. (GnuCvs-1-MC and
 GnuCvs-10-MC)
 The strange thing about this is that it plays better in level 1 than in
 level 10.

 Ben


 ___
 gnugo-devel mailing list
 gnugo-devel@gnu.org
 http://lists.gnu.org/mailman/listinfo/gnugo-devel




___
gnugo-devel mailing list
gnugo-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gnugo-devel


Re: [gnugo-devel] First Monte Carlo code ready for inclusion

2007-12-10 Thread Jens Yllman
If MC is implemented around GNU Go I thing that speed is more important then
the quality of the moves. That way low level is maybe better then high level.
MC is very dependent on speed.

Jens


 I've posted a new patch at http://trac.gnugo.org/gnugo/ticket/150 which
 contains a first version of my Monte Carlo code which should be in
 good enough shape to be added to CVS. It doesn't represent the full
 strength
 of the MonteGNU account on CGOS 9x9 but should at least suffice for a
 2000 rating there.

 To turn it on, use the option --monte-carlo. To set the number of
 Monte Carlo simulations per move, use the option --mc-games-per-level.
 That number (default 8000) is multiplied by the current level to give
 the actual number of simulations per move.

 Notice, however, that the --monte-carlo option will set the maximum
 allowed boardsize to 9x9. This is intentional because the code simply
 doesn't scale to larger boards. Of course anybody who is competent
 enough to modify the source code can change this, but I think that's
 a fair barrier.

 Please try it out.

 Now in CVS.
 I've put the CVS version on CGOS this weekend. (GnuCvs-1-MC and
 GnuCvs-10-MC)
 The strange thing about this is that it plays better in level 1 than in
 level 10.

 Ben


 ___
 gnugo-devel mailing list
 gnugo-devel@gnu.org
 http://lists.gnu.org/mailman/listinfo/gnugo-devel




___
gnugo-devel mailing list
gnugo-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gnugo-devel


Re: [gnugo-devel] First Monte Carlo code ready for inclusion

2007-12-10 Thread Jens Yllman
Sorry for my flooding the mailing list. This stupid mailer and the slow
computer just killing me sometimes.

Jens

 If MC is implemented around GNU Go I thing that speed is more important then
 the quality of the moves. That way low level is maybe better then high level.
 MC is very dependent on speed.

 Jens


 I've posted a new patch at http://trac.gnugo.org/gnugo/ticket/150 which
 contains a first version of my Monte Carlo code which should be in
 good enough shape to be added to CVS. It doesn't represent the full
 strength
 of the MonteGNU account on CGOS 9x9 but should at least suffice for a
 2000 rating there.

 To turn it on, use the option --monte-carlo. To set the number of
 Monte Carlo simulations per move, use the option --mc-games-per-level.
 That number (default 8000) is multiplied by the current level to give
 the actual number of simulations per move.

 Notice, however, that the --monte-carlo option will set the maximum
 allowed boardsize to 9x9. This is intentional because the code simply
 doesn't scale to larger boards. Of course anybody who is competent
 enough to modify the source code can change this, but I think that's
 a fair barrier.

 Please try it out.

 Now in CVS.
 I've put the CVS version on CGOS this weekend. (GnuCvs-1-MC and
 GnuCvs-10-MC)
 The strange thing about this is that it plays better in level 1 than in
 level 10.

 Ben


 ___
 gnugo-devel mailing list
 gnugo-devel@gnu.org
 http://lists.gnu.org/mailman/listinfo/gnugo-devel




 ___
 gnugo-devel mailing list
 gnugo-devel@gnu.org
 http://lists.gnu.org/mailman/listinfo/gnugo-devel




___
gnugo-devel mailing list
gnugo-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gnugo-devel


Re: [gnugo-devel] First Monte Carlo code ready for inclusion

2007-12-10 Thread Gunnar Farnebäck

Ben Lambrechts wrote:
 I've posted a new patch at http://trac.gnugo.org/gnugo/ticket/150 which
 contains a first version of my Monte Carlo code which should be in
 good enough shape to be added to CVS. It doesn't represent the full
 strength
 of the MonteGNU account on CGOS 9x9 but should at least suffice for a
 2000 rating there.

 To turn it on, use the option --monte-carlo. To set the number of
 Monte Carlo simulations per move, use the option 
--mc-games-per-level.

 That number (default 8000) is multiplied by the current level to give
 the actual number of simulations per move.

 Notice, however, that the --monte-carlo option will set the maximum
 allowed boardsize to 9x9. This is intentional because the code simply
 doesn't scale to larger boards. Of course anybody who is competent
 enough to modify the source code can change this, but I think that's
 a fair barrier.

 Please try it out.

 Now in CVS.
 I've put the CVS version on CGOS this weekend. (GnuCvs-1-MC and
 GnuCvs-10-MC)
 The strange thing about this is that it plays better in level 1 than in
 level 10.

What command line options are you using, more exactly?

/Gunnar


___
gnugo-devel mailing list
gnugo-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gnugo-devel


Re: [gnugo-devel] First Monte Carlo code ready for inclusion

2007-12-10 Thread Ben Lambrechts



What command line options are you using, more exactly?


tcl.exe cgos3.tcl GnuCvs-1-MC * gnugoMC.exe --mode gtp --cache-size 
512 --chinese-rules --level 1 --capture-all-dead --monte-carlo
tcl.exe cgos3.tcl GnuCvs-10-MC * gnugoMC.exe --mode gtp 
--cache-size 512 --chinese-rules --level 10 --capture-all-dead 
--monte-carlo




___
gnugo-devel mailing list
gnugo-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gnugo-devel


Re: [gnugo-devel] First Monte Carlo code ready for inclusion

2007-12-09 Thread Ben Lambrechts



I've posted a new patch at http://trac.gnugo.org/gnugo/ticket/150 which
contains a first version of my Monte Carlo code which should be in 
good enough shape to be added to CVS. It doesn't represent the full 
strength

of the MonteGNU account on CGOS 9x9 but should at least suffice for a
2000 rating there.

To turn it on, use the option --monte-carlo. To set the number of
Monte Carlo simulations per move, use the option --mc-games-per-level.
That number (default 8000) is multiplied by the current level to give
the actual number of simulations per move.

Notice, however, that the --monte-carlo option will set the maximum
allowed boardsize to 9x9. This is intentional because the code simply
doesn't scale to larger boards. Of course anybody who is competent 
enough to modify the source code can change this, but I think that's 
a fair barrier.


Please try it out.


Now in CVS. 
I've put the CVS version on CGOS this weekend. (GnuCvs-1-MC and 
GnuCvs-10-MC)
The strange thing about this is that it plays better in level 1 than in 
level 10.


Ben


___
gnugo-devel mailing list
gnugo-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gnugo-devel