At the Cotsen Open 1.5 years ago SlugGo beat an 8k, and lost on time
to his 8k brother, but the board position was a win by more than 100
points for SlugGo. But I agree that 10k is about right; SlugGo also
lost to a few 12k players.
I also agree that picking up 4 stones seems within reach,
At 01:51 PM 1/23/2007, you wrote:
Let me clear one thing up... I mean, a professional go player. ...
this would be equivalent to somewhere between 7-10 dan amateur.
at least decades. probably much longer. (at least without quantum stuff).
thanks
---
vice-chair http://ocjug.org/
_
At 01:22 PM 1/23/2007, you wrote:
... It plays the best game you could ever program it to play. How
fast would the computer have to be to beat a human? ... but I would
say a computer with perfect software, 32 GB of RAM (so a lot) and a
300 Mhz processor (slow processor) would be able to beat
Here are a few:
PubGo+ is a set of C++ classes for Go Programming by P. J. Leonard. It is
published under the GPL.
Effective Go Board Library by Łukasz Lew (he's active on this list).
HouseBot is an open source C++ program for playing the game of go (which I'm a
developer on).
I have been de
I strongly believe it's not hardware but software (ie. when we will
develop a strong enough algorithm) issue.
- gg
Nick Apperson: <[EMAIL PROTECTED]>:
>Let me clear one thing up... I mean, a professional go player. A rough
>approximation of what the human brain is capable of when it is optimi
Personally, I use the terminology in much the same way as Heikki. I
use the word "mistake" to describe (for example) a move that loses a
large group, but does not change the game from a win to a loss. It
makes sense to me to generally apply "mistake" to any move that loses
points relative to the
Hi folks,
I'm interested in doing some experiments in developing a computer go
algorithm. I definitely don't want to rewrite any of the basic stuff (board
management, scoring, etc) if it's already available somewhere. What's the
best library available (if any) for doing this kind of thing? If it
On Tue, 2007-01-23 at 15:22 -0600, Nick Apperson wrote:
> This is something I have been wrestling with. It is kind of a
> theoretical question. Assuming a program that utilizes all avaliable
> resources perfectly. It plays the best game you could ever program it
> to play. How fast would the co
Let me clear one thing up... I mean, a professional go player. A rough
approximation of what the human brain is capable of when it is optimized for
go compared with a computer that has its software optimized (not limited by
programming ability and programmer time) for go.
On 1/23/07, Joshua Shr
On Tue, Jan 23, 2007 at 10:35:08PM +0100, Heikki Levanto wrote:
> I just downloaded it and had a quick look.
Perfect timing - while I was writing my mail, you released 0.98
That works much more better. Now I get something like
playout_benchmark 100
=
Initial board:
komi 7
A B C D E
On Tue, 2007-01-23 at 21:08 +0100, [EMAIL PROTECTED] wrote:
> Yes. Don's scalability argument states that ELO gain is proportional
> to time doubling.
> For me scalable use of time implies that time translates into depth.
> The extra depth is:
>
> m - m0 = log(2)/log(b).
>
> So if the ELO gain
My 500mhz computer beats me fairly easy ;) with Gnugo so depends on
the person you're comparing.
-Josh
On 1/23/07, Nick Apperson <[EMAIL PROTECTED]> wrote:
This is something I have been wrestling with. It is kind of a theoretical
question. Assuming a program that utilizes all avaliable resour
The answer is "yes." Many computer programs (including my own) can beat me
easily on today's hardware and I am, indeed, a human.
Glad I could clear that up for you. ;-)
- Dave Hillis
-Original Message-
From: [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Tue,
On Mon, Jan 22, 2007 at 06:48:34PM +0100, ?ukasz Lew wrote:
> >Few interesting things has happened so I decided to announce new version:
Hi,
I just downloaded it and had a quick look. I am running on a
Debian/etch system, dual-core AMD-64.
Make finished fine, and the program seems to run. engine
This is something I have been wrestling with. It is kind of a theoretical
question. Assuming a program that utilizes all avaliable resources
perfectly. It plays the best game you could ever program it to play. How
fast would the computer have to be to beat a human? I could see people
argue th
you are right about my math being wrong. I wasn't paying that much
attention to that step, but with the correct math (as was pointed out) you
end up with a linear equation assuming what I said to assume. Man, its only
been a couple years and my precalc skills have gone to crap... Thanks for
the
On Sun, Jan 21, 2007 at 08:16:07PM -0800, Ray Tayek wrote:
> >I don't know the percentage of blunders. It also depends on what you
> >call a blunder. Is a 1 point mistake a blunder?
>
> no, maybe 10 or more points
My gut feeling is that a real blunder is enough to loose the game.
Between equally
About 2 months ago I sent a note to this email list about a research chair
position and a postdoc position, both financed through the SHACRNET High
Perfomance Consortium. The advert below does not have high performance
computing as a requisite attached. But because it mentions discrete math,
combi
- Oorspronkelijk bericht -
Van: Matt Gokey <[EMAIL PROTECTED]>
Datum: maandag, januari 22, 2007 9:59 pm
Onderwerp: Re: [computer-go] an idea... computer go program's rank vs
time
> Nick Apperson wrote:
>
> > He is saying this (I think):
> >
> > to read m moves deep with a branching fac
Here is another MC speedup trick. I think it may have been mentioned
before but it's worth repeating.
This applies to the case where my program is going to run N playout games
and then select the most visited node as its move for that turn (which will not
always be the node with the
Thanks.
This is fixed in v 0.98
Łukasz
On 1/23/07, terry mcintyre <[EMAIL PROTECTED]> wrote:
I was able to reproduce the problem with the odd "White Wins" value.
Turns out that win_cnt was not initialized in playout_benchmark. Adding an
explicit
initialization fixed that problem. My c++ is ex
I was able to reproduce the problem with the odd "White Wins" value.
Turns out that win_cnt was not initialized in playout_benchmark. Adding an
explicit
initialization fixed that problem. My c++ is extremely rusty, so I used
win_cnt[0]=0;
win_cnt[1]=0;
There is probably a c++ specific idiom
I will annoy You once again, because:
I added a mercy rule to the simple playout, and it turned out that it
is *faster* that my previous mega-optimised playout.
In current release old playout_t is gone, we have only simple_playout::run.
Some beautification, and helpful macros.
Also whole package
On 1/22/07, David Doshay <[EMAIL PROTECTED]> wrote:
Randomization of seed may not be a good idea. For some experiments it
is better to know the starting seed and keep it the same, for others,
like play against humans, randomization is probably preferable.
I would suggest having a runtime flag th
24 matches
Mail list logo
