On Tue, 2008-10-07 at 14:04 -0700, Christoph Birk wrote:
> name#light_simulations ELO
> myCtest-10k 1 1000
> myCtest-50k 5 1300
Ok, it looks like 1300 is a rough upper bound. At the moment I am
getting 1335 with 10,000 sims doing
On Wed, 8 Oct 2008, Don Dailey wrote:
Christoph,
Do you use all-moves-as-first? If not, this data seems to match mine
very well. The upper bound seems to be around 1300 ELO give or take a
few ELO.Ike seems to be around 1300 ELO with 10k play-outs but they
are all-as-first.I'll let it
Christoph,
Do you use all-moves-as-first? If not, this data seems to match mine
very well. The upper bound seems to be around 1300 ELO give or take a
few ELO.Ike seems to be around 1300 ELO with 10k play-outs but they
are all-as-first.I'll let it run a few days.
- Don
On Tue, 2008-1
I put up my old simple MC program on CGOS 9x9 as a reference bot.
It is called Ike and IkeJr, Ike does 1 playouts and IkeJr does
1000.
Here is how the play-outs work:
1. play uniformly random simulations.
2. Eye rule as described.
3. Play until no non-eye moves left, then pass.
4
On Tue, 7 Oct 2008, Denis fidaali wrote:
The engine is written in java, and run on a quad core Q9300 @ 2.50 Ghz.
The code has been lightly optimized, and use pseudo-liberties to detect
captures.
Run it on CGOS, it should get a similar rating to 'myCtest':
name#light_simulations
Hi Denis,
I wrote a simple java go program a couple of years ago that is very
basic non-tree monte carlo. Is yours tree based or simple?
I don't quite understand your eye rule but the standard one that I think
most of us are using is this:
an eye must ...
1. be surrounded by own stones on
Going from memory, that all looks right. (We've been calling it a "pseudo
eye".)
There's no need to do this, but for what it's worth, if you make a histogram of
the scores,
- you should only get odd scores
- there should be big spikes at the tails (+/- 81)
- there should be a Gaussian-looking
