Brian Sheppard wrote:
Fuego uses a lower weight for distant moves than for nearby moves.
I suspect that isn't much better than using uniform weight. I am
hope that Martin or Markus will comment.
I measured a winning rate of 55.1(+-0.8)% of Fuego with weighted RAVE
updates vs. the version w
terry mcintyre wrote:
Does Fuego make use of multiple cores? Does it require some switch setting to
do so?
The number of threads is controlled by the GTP command "uct_param_search
number_threads". On Intel and AMD CPUs, you should also set
""uct_param_search lock_free 1", see
http://www
Jason House wrote:
I went back to take another look and here are some of the things I'm
noticing immediately:
* There's both a go and gouct directory. They share many of the
same file names (after removing the path-dependent name mangling
such as GoBoard.cpp and GoUctBoard.cpp)
Petr Baudis wrote:
Just FYI, someone might find interesting that latest SVN of Fuego
still does not seem to be on par with Mogo public release 1 (not that it
would claim to be - I was just curious where do they stand against each
other).
Fuego is weaker than MoGo on 19x19. With 15 min game
Rémi Coulom wrote:
Yes. The recipe is:
- play as usual with Chinese rules,
- take a one-point security margin with respect to komi,
- pass as soon as the opponent passes.
You also have to be careful to score seki the Japanese way in the
playouts. This is the most difficult part. If your playou
Gunnar Farnebäck wrote:
Markus Enzenberger wrote:
> I connected Fuego configured with CGOS rules. After a while it
> terminated, because Fuego returned an error response to a play command
> with a move that violated the positional superko rule. (By default,
> Fuego does not accept i
Gunnar Farnebäck wrote:
To do that, just point your regular cgos client to trac.gnugo.org,
port 6867.
what rules does GNU Go use in the 6x6 analysis?
I connected Fuego configured with CGOS rules. After a while it
terminated, because Fuego returned an error response to a play command
with a m
Don Dailey wrote:
If someone else could please run an anchor until we get this ironed out,
it would be appreciated.
Contact me by private email if you can run a reliable anchor player for
a while.
I could run a GNU Go anchor on 19x19 on one of our machines for two
weeks. Maybe even a few w
David Fotland wrote:
I prefer keeping 9x9. We have 9x9 for quick testing of changes (because the
games are fast), and 19x19 for testing play on a full board. I don't think
13x13 adds anything. It's slower, so I would still use 9x9 for quick tests.
It's not a board size that anyone uses, so I w
Rémi Coulom wrote:
This seems to be a good solution. I have just applied to your
computer-go group. We just have to try to import the bibtex file.
Markus, can you do it ? Or tell us where to download the bibtex file ?
I added a link to the bib-file on the website:
http://www.cs.ualberta.ca/~g
Rémi Coulom wrote:
I could not find the link for suggesting updates to the computer go
bibliography, so if the people from the University of Alberta read
this, they might like to add those papers to their bibliography.
I probably won't continue maintaining the bibliography (from the
beginning
Jason House wrote:
What enhancements does fuego have over plain vanilla UCT? Also, what
hardware are you using? The name seems to imply it's running with 8
cores.
the enhancements are probably similar to what the other programs use:
MoGo-like patterns and other heuristics in the playout po
Remi Munos wrote:
I have updated the BAST paper, providing additional comparison with UCT, as
suggested by one person in the list. See: https://hal.inria.fr/inria-00150207
after reading the paper, I have two questions:
How did you deal with unexplored nodes in Flat UCB and BAST in your
expe
On Mon October 22 2007 18:24, Don Dailey wrote:
> > On Mon October 22 2007 10:15, Don Dailey wrote:
> > it also seems to be hard to write an SGF file without bugs.
>
> 20% of the games or 20% of the sources? 20% of the games could have
> come from a single source.
from different sources. You can
On Mon October 22 2007 10:15, Don Dailey wrote:
> almost impossible to write XML manually without bugs.
it also seems to be hard to write an SGF file without bugs.
I recently run a test on a collection of about 5000 SGF files
from various sources on the web and more than 20% of them
generated a wa
On Monday 10 September 2007, Sylvain Gelly wrote:
> Ah, now that makes sense, the additional number you posted on your
> email was actually sent to MoGo, and I understand now why it did not
> work.
auto-numbering in GoGui prepends all commands with an integer ID,
which is sent to the program and s
On Monday 10 September 2007, Sylvain Gelly wrote:
> > could it be that it is compiled for specific CPU architecture?
>
> Of course it is :).
> Ok, good (well, rather sad :)), to know that it does not work on
> Athlon XP. I should rebuild with an older architecture then (but it
> will be slower :-(
> when I run the Linux exeutable on my Fedora 8/Athlon XP, I get a
I mean Fedora 7...
- Markus
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
when I run the Linux exeutable on my Fedora 8/Athlon XP, I get a
coredump:
$ mogo --9 --time 12
Load opening database opening succeed (nbEntries=618) (nbIllegalMoves removed
0)
tried to open opening, success 1
Illegal instruction (core dumped)
could it be that it is compiled for specific CPU arc
I am still frightened by your plans, how to permit asynchronous commands in
GTP. Here are some remarks and questions:
genmove is only one of many commands that the user might want to abort. We use
GTP extension commands for starting life and death searches or other lengthy
computations and many
On Saturday 03 March 2007, Stuart A. Yeates wrote:
> In an ideal world I'd love to see go move to RFC 3920, but that would
> be quite a disruptive shift.
this RFC describes an asynchronous message passing system; GTP is more like a
simple remote procedure call at Go engines.
These are different
On Thursday 01 March 2007, Phil G wrote:
> I would like to suggest using the command "setup_sequence" instead to miror
> the "play_sequence" command which was introduced by GoGui (I believe).
I finally followed the GTP (draft) standard and used a prefix separated by a
hyphen for non-standard exte
On Thu March 1 2007 05:22, Łukasz Lew wrote:
> The most important thing is controller - engine architecture.
> There are situations that engine would like to have the control. For
these requests come up once in a while, but IMO the clear separation between
who is the controller and the engine is
On Wednesday 21 February 2007, Chris Fant wrote:
> It seems that GtpStatistics (java tool that comes in the GoGui
> package) is not sending a quit command to my gtp player. This results
> in me having to manually kill the gtp player process after each run.
please report GoGui bugs to the GoGui bu
On Monday 19 February 2007, Chris Fant wrote:
> Here is a completed game of Go between two random players... on a very
> large board.
>
> For ascetics, the eyes have been filled after both players passed.
>
> http://fantius.com/RandomGo1600x1200.png
this is very interesting. Can you compute some p
would it make sense to treat players with handicap as completely different
players? For example, GNU Go giving one handicap stone would be a different
player and get a rating independent of GNU Go in an even game?
Then there is no problem about how to shoehorn handicap into the ELO system.
It w
On Friday 22 December 2006 13:24, Christian Nilsson wrote:
> How is this compensation handled by the various programs on cgos, if at
> all?
>
> Check http://www.britgo.org/rules/compare.html#comp if you don't know
> what I'm talking about..
is there any logical explanation for this rule? I mean, W
On Tue December 5 2006 13:31, Don Dailey wrote:
> On CGOS, gnugu_3.7.4 is rated 1720. MoGo is is in the 2100-2200,
> presumably it's save to assume it is significantly stronger.
>
> But if we can assign an ELO rating to Gnugo 3.7.4, then we can add 300
> or 400 to get Mogo's current ELO rating.
28 matches
Mail list logo
