LOLCODE
http://lolcode.com/
The future of programing.
-?Dave Hillis
-Original Message-
From: Don Dailey [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Mon, 1 Oct 2007 3:45 pm
Subject: Re: [computer-go] Python bindings for libego?
-BEGIN PGP SIGNED MESSAGE-
Greetings,
I noticed that the following link was recently added to the Computer
Go Wikipedia article.
http://www.spectrum.ieee.org/oct07/5552 Cracking Go, by Feng-hsiung
Hsu, IEEE Spectrum magazine, October 2007.
He claims it should be possible to build a Go machine stronger than
any
Hi,
Has anyone else done scaling experiments with 19x19 and UCT?
I did some months ago, and reported them in that list with the title
19x19 Go, scalability with time vs handicap
(http://www.mail-archive.com/computer-go%40computer-go.org/msg02775.html)
The results are old, but now everyone can
Le mardi 2 octobre 2007 16:46, Ian Osgood a écrit :
Greetings,
I noticed that the following link was recently added to the Computer
Go Wikipedia article.
http://www.spectrum.ieee.org/oct07/5552 Cracking Go, by Feng-hsiung
Hsu, IEEE Spectrum magazine, October 2007.
He claims it should be
I think he is betting on null move proving - but I'm real skeptical that
it will be effective in Computer Go. It will indeed reduce the tree
IMHO null-move mixes badly with ko-tactics, effectively doubling
(or squaring ? ;-) the tree size.
It might be of some use in solving local
Hi,
This are the game collections I use:
http://www.u-go.net/gamerecords/ 55000+ games of strong players on KGS
(free, lots of handicap games)
http://www.go4go.net/v2/ 16000+ recent professional games (not free, but
very good collection)
-Oorspronkelijk bericht-
Van: [EMAIL PROTECTED]
- Original Message
From: Don Dailey [EMAIL PROTECTED]
I think [Hsu] is betting on null move proving - but I'm real skeptical that
it will be effective in Computer Go. It will indeed reduce the tree
significantly, but this comes at a qualitative price that is not so bad
in Chess but
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I don't believe null move pruning will be effective in Go. The basic
principle of null move pruning has been described in a couple of ways:
1. threat analysis
2. bounds checking.
It does both things - this is more about how to think about it.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It still has the scent of alpha-beta-with-some-evaluation-function,
which is probably not the right paradigm for go.
No matter how you slice it, the problem is evaluation. I'm a strong
believe in tree search, but it must be combined with
The null move test is to play 2 moves in a row for one side and consider
the result an upper bound. (or conversely to consider the result a
lower bound for the other side.)
I take it that without a good evaluation function to distinguish the value of a
move with other moves one or two ply
On 10/2/07, Phil G [EMAIL PROTECTED] wrote:
Also, is it just me that a good evaluation function early in the game is
difficult to write?
I think it's doable. It's just not trivial. Simple pattern matching should
give a reasonable approximation for corner spats at the start of the game.
From my conversations with dan-level players, analysis in the fuseki is not
broad. They'll consider a handful of moves at any point - should I play in the
open corner first, or respond to an approach move, or make my own approach
move? Candidate moves are chosen from a small set of patterns -
On Oct 2, 2007, at 10:33 AM, Phil G wrote:
On a slight different topic, for those of you with experience
writing an evaluation function for an alpha-beta search, do you use
the number of total moves played to weight different parts of the
evaluation function? For example, it is easier
Hsu wrote:
If we assume the top Go players calculate about as deeply as the top
chess players do, the result should be a machine that plays Go as well
as Deep Blue played chess.
I don't think this assumption holds.
A high level player reads 25-30 ply sequences (very low branching, but
not a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I don't think he was talking about this kind of reading, strong chess
players also read in this sense.Especially in the end games where
you might envision then next 10 moves or more (which is 20 ply or more.)
It's harder to do in chess (because
On Tue, 2 Oct 2007, Don Dailey wrote:
I don't think he was talking about this kind of reading, strong chess
players also read in this sense.
What other kind of reading is there? I was am talking about the
common term (in Go and Chess) reading ahead.
It's harder to do in chess (because the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
He wasn't talking about reading at all. I was being nice when I said
he wasn't talking about that kind of reading - giving you the benefit of
the doubt.
- - Don
Christoph Birk wrote:
On Tue, 2 Oct 2007, Don Dailey wrote:
I don't think he was
On Tue, Oct 02, 2007 at 12:27:28PM -0400, Don Dailey wrote:
I don't believe null move pruning will be effective in Go. The basic
principle of null move pruning has been described in a couple of ways:
1. threat analysis
2. bounds checking.
In go terms, doesn't that translate to
On Tue, Oct 02, 2007 at 06:02:53PM +0200, Alain Baeckeroot wrote:
Unless i missed something in this 4 pages article, there is nothing in it !
Just vague phrase, and assumption that brute force (ala deep blue) _may_ give
a strong go machine.
I think classical, MC and UCT programmers have
On Tue, Oct 02, 2007 at 10:33:09AM -0700, Phil G wrote:
Also, is it just me that a good evaluation function early in the game is
difficult to write?
No, it is not you. The rest of people can be divided in two groups. Some
believe such a function is easy to write. Let them come forth and show
I wouldn't put it as strongly, but I also noticed that MC and UCT and suclike
techniques were not mentioned at all.
to be fair to the article, in fact they were. you just have to click on all of
the
links in the article to see it.
s.
I wouldn't put it as strongly, but I also noticed that MC and UCT and suclike
techniques were not mentioned at all.
to be fair to the article, in fact they were. you just have to click on all
of the
links in the article to see it.
For others, like me, who missed the link, it is here:
For others, like me, who missed the link, it is here:
http://www.spectrum.ieee.org/oct07/5552/monte
But this is just talking about monte carlo; no mention of UCT, which (as
Don said earlier in this thread) is the best (global) search algorithm
we have right now, and it would be dangerous
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christoph Birk wrote:
On Tue, 2 Oct 2007, Don Dailey wrote:
He wasn't talking about reading at all. I was being nice when I said
he wasn't talking about that kind of reading - giving you the benefit of
the doubt.
Please explain what he meant
Mogo is very strong, definitely dan level, at all parts of the game
(except the first 10 moves, where it can be a bit fuzzy; Note: I've only
been testing it at 9x9). It's understanding of sente and gote in a close
endgame is outstanding. I thought I had found weak play with monkey
jumps, and with
Many Faces does not use null move, but does extensive caching of life and
death and other tactical results.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of terry mcintyre
Sent: Tuesday, October 02, 2007 9:21 AM
To: computer-go
Subject: Re: [computer-go]
26 matches
Mail list logo
