Re: [Computer-go] AlphaGo Zero SGF - Free Use or Copyright?

[terry mcintyre via Computer-go]

Petri and Tom are correct; "intuition" and "subconscious" and "unobserved 
thought" are names for the same idea. 
AlphaGo Zero's neural network, regardless of how well it simulates human 
neurons or not, cannot be described as being similar to what we think of as the 
logical, rule-driven part of the human thought process; it is much more akin to 
the "intuition" or "subconscious" of a highly experienced player, wrapped 
together with a very logical process akin to what we humans call "reading." 
Terry McIntyre <terrymcint...@yahoo.com> Unix/Linux Systems Administration 
Taking time to do it right saves having to do it twice. 

On Sunday, October 29, 2017, 6:42:27 AM EDT, Petri Pitkanen 
<petri.t.pitka...@gmail.com> wrote:  
 
 intuition is handy word for truly automated information processing i.e 
subconscious.   And everything that train conscious decission making trains 
also the subconscious/intuiton. Intuiton nothing mythical just automation 
achieved via training
2017-10-29 5:08 GMT+02:00 Thomas Rohde <t...@bonobo.com>:

On 2017-10-28 at 16:36, Robert Jasiek <jas...@snafu.de> wrote:

> IMO, intuition does not exist; it is nothing but an excuse for not 
> understanding subconscious or currently unobservable thinking yet. Can we 
> speak of human subconscious thinking, please?

Uhm, I always thought the short word for “subconscious thinking” was 
“intuition” ;-)

Reminds me of “A Table is a Table” (orig. “Ein Tisch ist ein Tisch”), a short 
story by Swiss writer Peter Bichsel

—> https://vimeo.com/11331609 (ten minutes video, English version)
—> https://vimeo.com/8749843 (German version)

“What's in a name? that which we call a rose
By any other word would smell as sweet”
— Shakespeare


Greetings, Tom

--
Thomas Rohde
Wiesenkamp 12, 29646 Bispingen, GERMANY
--
t...@bonobo.com
__ _
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/ mailman/listinfo/computer-go

___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Source code (Was: Reducing network size? (Was: AlphaGo Zero))

[terry mcintyre via Computer-go]

I'm sorry, did I miss soemthing here? 
On Friday, October 27, 2017, 5:46:19 AM EDT, Gian-Carlo Pascutto 
 wrote:  
 
 On 27-10-17 00:33, Shawn Ligocki wrote:
> But the data should be different for different komi values, right? 
> Iteratively producing self-play games and training with the goal of 
> optimizing for komi 7 should converge to a different optimal player 
> than optimizing for komi 5.

"For the policy (head) network, yes, definitely. It makes no difference
to the value (head) network."


The value network indicates whether the board leads to a win or not. This would 
certainly depend on komi, especially in the half-point games which seem to be 
the natural end result of how it selects moves? 

___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go  ___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] dealing with multiple local optima

[terry mcintyre via Computer-go]

"seeing" is complex when the input is just a bunch of pixels.  Terry McIntyre 
 Unix/Linux Systems Administration Taking time to do 
it right saves having to do it twice. 

On Friday, February 24, 2017 12:32 PM, Minjae Kim <xive...@gmail.com> wrote:
 

 But those video games have a very simple optimal policy. Consider Super Mario: 
if you see an enemy, step on it; if you see a whole, jump over it; if you see a 
pipe sticking up, also jump over it; etc.

On Sat, Feb 25, 2017 at 12:36 AM, Darren Cook <dar...@dcook.org> wrote:

> ...if it is hard to have "the good starting point" such as a trained
> policy from human expert game records, what is a way to devise one.

My first thought was to look at the DeepMind research on learning to
play video games (which I think either pre-dates the AlphaGo research,
or was done in parallel with it): https://deepmind.com/research/ dqn/

It just learns from trial and error, no expert game records:

http://www.theverge.com/2016/ 6/9/11893002/google-ai- 
deepmind-atari-montezumas- revenge

Darren



--
Darren Cook, Software Researcher/Developer
My New Book: Practical Machine Learning with H2O:
  http://shop.oreilly.com/ product/0636920053170.do
__ _
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/ mailman/listinfo/computer-go


___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

   ___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] AlphaGo rollout nakade patterns?

[terry mcintyre via Computer-go]

 blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px 
#715FFA solid !important; padding-left:1ex !important; background-color:white 
!important; } I speculate: nakade involves creating a shape (such as three in a 
row or a bulky five) such that, if captured, it would only form one eye, given 
the proper placement. I can imagine a set of patterns which enumerate the 
possibilities. Some examples exist, however, which are quite complex. 


Sent from Yahoo Mail for iPad


On Monday, January 23, 2017, 11:45 AM, Roel van Engelen  
wrote:

I am trying to re-create the fast rollout policy as described by deepMind but 
got stuck on the nakade patterns:
"Nakade, # of patterns 8192: Move matches a nakade pattern at captured stone"

the "at captured stone" confuses me, my first thought is: "this is only 
computed if stones have been captured recently" but i don't think that is 
correct. how should i read it?
since they say "# of patterns 8192" i imagine they found some way to hash them 
just like the 3x3 and 12point diamond shapes but so fari have not found a way 
to do so. I found that other engines use heuristics to find nakade patterns so 
my question is does AlphaGo use patterns and does somebody know how this works?
Thanks!
Roel___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go


___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Are the AlphaGols coming?

[terry mcintyre]

 blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px 
#715FFA solid !important; padding-left:1ex !important; background-color:white 
!important; } During its training, AlphaGo played many handicap games against a 
previous version of itself, so the team and the program are acquainted with 
handicap play. I don't recall reading any discussion of komi experiments. 
Google's advantage is that they can dynamically spin up bunches of processors 
to try all sorts of experiments, including tournaments designed to test various 
versions, theories, and tweaks. There was some discussion about what to do if 
one could spin up thousands of processr cores on demand. 
There are surely large businesses in China which could do the same. They have 
similar reasons to pursue deep learning and other creative uses of big data and 
supercomputing. 


Sent from Yahoo Mail for iPad


On Thursday, January 5, 2017, 9:36 PM, David Ongaro  
wrote:This discussion reminds me of an incident which happened at the EGC in 
Tuchola 2004 (maybe someone can find a source for this). I don’t remember all 
details but it was about like this:


Two amateur players where analyzing a Game and a professional player happened 
to come by. So they asked him how he would assess the position. After a quick 
look he said “White is leading by two points”. The two players where wondering: 
“You can count that quickly?”, but the pro answered “No, I just asked myself if 
I would like to have black in this position. The answer is no. But with two 
extra Komi for Black it would feel ok.”
So it seems professionals already acquired some kind of “value network” due to 
their hard training, but they also can modify its assessments by taking Komi 
into account. Maybe that's something we also should do, i.e. not only train the 
value network by taking go positions and results into account but also add the 
Komi as an input (the output would still be a simple win/lose result). In that 
way we don’t have to train a different network for each Komi, even though the 
problem getting enough training data for all Komi values still remains.


On Jan 5, 2017, at 11:44 AM, David Ongaro  wrote:


On Jan 5, 2017, at 2:37 AM, Detlef Schmicker  wrote:

Hi,

what makes you think the opening theory with reverse komi would be the
same as with standard komi?

I would be afraid to invest an enormous amount of time just to learn,
that you have to open differently in reverse komi games :)


Thats why I used the comparative adjective “less”. It might not be ideal, but 
still much better than changing the fundamental structure of the opening with 
an extra stone. Furthermore the effect might not as big as you think:

1. The stronger player doesn’t have to play overplays when the handicap is 
correct. If the handicap is correct and if AlphaGo “knows” that is another 
question though… Of course the weaker player might play differently (i.e. more 
safely) but at least that is something he or she can control
2. One could even argue the other way around:  we might see more sound 
(theoretically correct) moves from AlphaGo with reverse Komi. If it's seeing 
itself ahead already during the opening it might resort to slack but safe 
moves. Since it’s still winning we can be left wondering if it was actually a 
good move. But if it does an unusual looking move which it can’t be considered 
an overplay but it’s still winning in the end with reverse Komi there should be 
a real insight to gain.

Still, a reverse Komi handicap is rather big, but it might be the next best 
thing we have without retraining the value network from scratch. Furthermore 
retraining the value network will probably affect the playing style even more.

Thanks,

David O.



Am 05.01.2017 um 10:50 schrieb Paweł Morawiecki:

2017-01-04 21:07 GMT+01:00 David Ongaro :



[...]So my question is: is it possible to have reverse Komi games
by feeding the value network with reverse colors?



In the paper from Nature (subsection "Features for policy/value
network"), authors state:

*the stone colour at each intersection was represented as either
player or opponent rather than black or white. *

Then, I think the AlphaGo algorithm would be fine with a reverse
komi. Namely, a human player takes black and has 7.5 komi. The next
step is that AlphaGo gives 2 stones of handicap but keeps 7.5 komi
(normally you have 0.5).

Aja, can you confirm this?



Also having 2 stone games is not so interesting since it would
reveal less insights for even game opening Theory.



I agree with David here, most insights we would get from even
games. But we can imagine the following show. Some games are played
with a reverse komi, some games would be played with 2 stones (yet,
white keeps 7.5 komi) and eventually the main event with normal
even games to debunk our myths on the game. Wouldn't be super
exciting!?

Best regards, Paweł

Re: [Computer-go] it's alphago

[terry mcintyre]

It's one thing to know the recipe; it's another to have an industrial-size 
kitchen. Google was able to throw truly gargantuan amounts of computing 
resources at this problem. 

A few years back, a researcher - was it  Remi Coulon? - was able to scrounge a 
few thousand cores for a tournament. Google designed an ASIC specifically for 
the task of accelerating their neural networks, and made thousands of them 
available for massive tests and training.  Terry McIntyre 
<terrymcint...@yahoo.com> Unix/Linux Systems Administration Taking time to do 
it right saves having to do it twice.tr 

On Thursday, January 5, 2017 9:01 AM, Stefan Kaitschick 
<skaitsch...@gmail.com> wrote:
 

 

Honestly I got a little frustrated that many people didn't think that
was AlphaGo. It was almost clear to me because I know the difficulty of
developing AlphaGo-like bots.



 I feel with you. People seem to think that the Nature paper gave away the full 
recipe.

___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

   ___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Nice graph

[terry mcintyre]

 blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px 
#715FFA solid !important;  padding-left:1ex !important; background-color:white 
!important; }  It's never wise to generalize too much from one data point.  
AlphaGo 2.0 is very very good at defeating AlphaGo 1.0. 
This does not make 2.0 a 10 dan pro. 
If it beat a succession of 9 dan pros, the claim would be credible.

I think David Silver knows this. I think he and his team are studying Game 4 
very closely, and are working on the 3.0 version. And I notice that all the top 
programs are taking a close look at DCNN now. 

Sent from Yahoo Mail for iPad


On Friday, March 25, 2016, 7:48 PM, Petr Baudis  wrote:

The thread is

    http://www.lifein19x19.com/forum/viewtopic.php?f=18=12922=201695

On Fri, Mar 25, 2016 at 09:16:07PM -0400, Brian Sheppard wrote:
> Hmm, seems to imply a 1000-Elo edge over human 9p. But such a player would 
> literally never lose a game to a human.
> 
> I take this as an example of the difficulty of extrapolating based on games 
> against computers. (and the slide seems to have a disclaimer to this effect, 
> if I am reading the text on the left hand side correctly). Computers have 
> structural similarities that exaggerates strength differences in head-to-head 
> comparisons. But against opponents that have different playing 
> characteristics, such as human 9p, then the strength distribution is 
> different.

I agree.  Well, computer vs. computer may be still (somewhat) fine as long
as it's different programs.  What I wrote in that thread:

The word covered by the speaker's head is "self".  Bot results in
self-play are always(?) massively exaggerated.  It's not uncommon to see
a 75% self-play winrate in selfplay to translate to 52% winrate against
a third-party reference opponent.  c.f. fig 7&8 in
http://pasky.or.cz/go/pachi-tr.pdf . Intuitively, I'd expect the effect
to be less pronounced with very strong programs, but we don't know
anything precise about the mechanics here and experiments are difficult.

It's no doubt today's AlphaGo is much stronger than the Nature version.
But how much?  We'll have a better idea when they pit it in more matches
with humans, and ideally when other programs catch up further.  Without
knowing more (like the rest of the slides or a statement by someone from
Deepmind), I wouldn't personally read much into this graph.

-- 
                Petr Baudis
    If you have good ideas, good data and fast computers,
    you can do almost anything. -- Geoffrey Hinton
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
 

___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Finding Alphago's Weaknesses

[terry mcintyre]

 blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px 
#715FFA solid !important;  padding-left:1ex !important; background-color:white 
!important; }  According to the paper, AlphaGo did not use an opening book at 
all, in the version which played Fan Hui.
Hypothetically, they could have grafted one on. I read a report that the first 
move in game 2 vs. Lee Sedol took only seconds. On the other hand, it's first 
move in game 1 took a longer while. We can only speculate. 


Sent from Yahoo Mail for iPad


On Thursday, March 10, 2016, 12:31 PM, uurtamo .  wrote:


Quick question - how, mechanically, is the opening being handled by alpha go 
and other recent very strong programs? Giant hand-entered or game-learned 
joseki books?

Thanks,

steve
On Mar 10, 2016 12:23 PM, "Thomas Wolf"  wrote:

My 2 cent:

Recent strong computer programs never loose by a few points.  They are either
crashed before the end game starts (because when being clearly behind they play 
more
desperate and weaker moves because they mainly get negative feadback from
their search with mostly loosing branches and risky play gives them the only
winning sequences in their search) or they win by resignation or win
by a few points.

In other words, if a human player playing AlphaGo does not have a large
advantage already in the middle game, then AlphaGo will win whether it looks
like it or not (even to a 9p player like Michael Redmond was surprised
last night about the sudden gain of a number of points by AlphaGo in the
center in the end game: 4:42:10, 4:43:00, 4:43:28 in the video 
https://gogameguru.com/alphago-2/)

In the middle and end game the reduced number of possible moves and the
precise and fast counting ability of computer programs are superior.  In the
game commentary of the 1st game it was mentioned that Lee Sedol considers the
opening not to be his strongest part of the game.  But with AlphaGo playing
top pro level even in the opening, a large advantage after the middle game
might simply be impossible to reach for a human.

About finding weakness:
In the absense of games of AlphaGo to study it might be interesting to get a 
general idea by checking out the games where 7d Zen lost on KGS
recently.

Thomas

On Thu, 10 Mar 2016, wing wrote:


One question is whether Lee Sedol knows about these weaknesses.
Another question is whether he will exploit those weaknesses.
Lee has a very simple style of play that seems less ko-oriented
than other players, and this may play into the hands of Alpha.

Michael Wing


 I was surprised the Lee Sedol didn't take the game a bit further to
 probe AlphaGo and see how it responded to [...complex kos, complex ko
 fights, complex sekis, complex semeais, ..., multiple connection
 problems, complex life and death problems] as ammunition for his next
 game. I think he was so astonished at being put into a losing
 position, he wasn't mentally prepared to put himself in a student's
 role again, especially to an AI...which had clearly played much weaker
 games just 6 months ago. I'm hopeful Lee Sedol's team has been some
 meta-strategy sessions where, if he finds himself in a losing position
 in game two, he turns it into exploring a set of experiments to tease
 out some of the weaknesses to be better exploited in the remaining
 games.

 On Thu, Mar 10, 2016 at 8:16 AM, Robert Jasiek  wrote:

>  On 10.03.2016 00:45, Hideki Kato wrote:
> > >  such as solving complex semeai's and double-ko's, aren't solved yet.
> >  To find out Alphago's weaknesses, there can be, in particular,
> >  - this match
>  - careful analysis of its games
>  - Alphago playing on artificial problem positions incl. complex kos, >  
>complex ko fights, complex sekis, complex semeais, complex endgames, >  
>multiple connection problems, complex life and death problems (such as >  Igo 
>Hatsu Yoron 120) etc., and then theoretical analysis of such play
>  - semantic verification of the program code and interface
>  - theoretical study of the used theory and the generated dynamic data >  
>(structures)
> >  --
>  robert jasiek
>  ___
>  Computer-go mailing list
>  Computer-go@computer-go.org
>  http://computer-go.org/mailman/listinfo/computer-go [1]



 Links:
 --
 [1] http://computer-go.org/mailman/listinfo/computer-go

 ___
 Computer-go mailing list
 Computer-go@computer-go.org
 http://computer-go.org/mailman/listinfo/computer-go

___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go


___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

___
Computer-go mailing list
Computer-go@computer-go.org

Re: [computer-go] Re: Open source real time Go server

[terry mcintyre]

When SE fails, it is often blatantly obvious: a group is dead or in seki, but 
judged to be alive; or vice versa. 


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: Open source real time Go server

[terry mcintyre]

It's all about expectations -- at this point, we don't expect any SE to say at 
move 10: This is a half-point win for white. ( I recall a pro making such an 
observation; I was willing to accept his expertise on the matter. )

But if it says at move 160: White wins by 5 points, it should be in the 
ballpark - or at least not so far out of the ballpark that a 16 kyu player 
wonders whether it might be playing in the wrong field entirely. 


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: Open source real time Go server

[terry mcintyre]

If accessibility is the only criterion, a client would do the trick; it would 
need an open protocol.

It's been a bit of an inconvenience that KGS does not publish an open-protocol 
interface. 

As for other things we'd like to see improved, we could build a list. My pet 
peeve is the KGS score estimator, which is often wildly wrong. I've heard 
complaints about the implementation of the rules, and some have argued that it 
is not terribly bot-friendly. 

 Terry McIntyre terrymcint...@yahoo.com


Everyone wants to live at the expense of the state. They forget that the state 
wants to live at the expense of everyone. --Frederic Bastiat


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: Open source real time Go server

[terry mcintyre]

If the protocol isn't open, it can be changed. It is believed that wms did just 
that to frustrate open-source clients. There may be some justification to his 
argument that buggy clients were causing problems with his server. 

 From: Michael Williams michaelwilliam...@gmail.com


Even though KGS is not open, you can still reverse engineer it, right?  Why 
not create an accessible web interface to KGS?

terry mcintyre wrote:
 If accessibility is the only criterion, a client would do the trick; it 
 would need an open protocol.
 
 It's been a bit of an inconvenience that KGS does not publish an 
 open-protocol interface.
 
 As for other things we'd like to see improved, we could build a list. My pet 
 peeve is the KGS score estimator, which is often wildly wrong. I've heard 
 complaints about the implementation of the rules, and some have argued that 
 it is not terribly bot-friendly.
  Terry McIntyre terrymcint...@yahoo.com

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: Open source real time Go server

[terry mcintyre]

When I say the SE is wildly off, I'm not referring to positions which only a 
pro could evaluate but positions which a double-digit kyu player could 
correctly evaluate.


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] problem which current programs have difficulty solving

[terry mcintyre]

A high dan-level player ( to which our programs aspire ) would play it 
properly. 

I'm a mid-kyu player, and I find these solutions about half the time, and half 
not; that's why I am not a dan-level player, lol.

GnuGo does have a method ( dragon status ) to explicitly ask is this group 
alive or dead?

Correction to my post: the title is Rescue and Capture. 





From: Stefan Kaitschick stefan.kaitsch...@hamburg.de
  
I wouldn't consider not solving this 
pathological.
I think it's a pretty difficult 
problem.
Without a problem warning most amateur 
players would miss it too.
You can't force life and you can't force 
connection. The either-or is easy to miss.
 
Stefan 
 
- Original Message - 
From: terry 
  mcintyre 
To: computer go 
Sent: Sunday, December 20, 2009 7:03 
  PM
Subject: [computer-go] problem which 
  current programs have difficulty solving


This 
  gem is from one of Yilun Yang's little pocket-sized books - I think it is 
  called Recovery And Connections. 

Neither Gnugo, Fuego, nor Many Faces 
  of Go is able to solve it. Fuego came closest, recognizing the best black 
  move, but a few moves later, it lost interest and played elsewhere. GnuGo 
  rejects the winning move as unsafe.

Btw, GoGui/Gnugo have a method to 
  find dragon status; is there something comparable with Fuego/GoGui?

 Terry McIntyre terrymcint...@yahoo.com




  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] problem which current programs have difficulty solving

[terry mcintyre]

This gem is from one of Yilun Yang's little pocket-sized books - I think it is 
called Recovery And Connections. 

Neither Gnugo, Fuego, nor Many Faces of Go is able to solve it. Fuego came 
closest, recognizing the best black move, but a few moves later, it lost 
interest and played elsewhere. GnuGo rejects the winning move as unsafe.

Btw, GoGui/Gnugo have a method to find dragon status; is there something 
comparable with Fuego/GoGui?

 Terry McIntyre terrymcint...@yahoo.com


“Politics should be limited in scope to war, protection of property, and the 
occasional precautionary beheading of a member of the ruling class.”  P.J. 
O'Rourke



  

test.sgf
Description: Binary data
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: Hahn system tournament and MC bots

[terry mcintyre]

From: Vlad Dumitrescu vladd...@gmail.com

I'm sorry to bother you, but I don't get it. There must be some subtle
detail that escapes me...

Please try to explain why the hahn calculation isn't working in a
normal game so as to ensure a win. I'm talking about strong human
players.

In my view, we have
hahn: object of the game = max board score
normal:  object of the game = board score  komi
Both seem just as easy and interesting.

If you are winning in the Hahn sense, your score also exceeds komi; but Hahn 
scoring - either by accumulating points in a tournament ranking, or converting 
points to dollars in bang neki fashion, gives you incentive to achieve larger 
scores. 

Under the board score  komi regime, if you have a group which might be 
invaded (at some risk of losing points), but which can be safely walled off, I 
might choose to wall it off if my overall score is sufficient to win.  Under 
Hahn scoring, a rational player would probably invade, in order to maximize the 
expected win.

In some sense, half a point is good enough may be easier for such situations 
- the safe strategy is easier to compute; seal the borders and count, if you 
have enough, you're done. Smart players will economize - rich men don't pick 
fights - the game will progress to simpler, more easily-analyzed paths, where 
the outcome is certain. 

In a way, this is like an Indian parable: a sultan decreed that his daughter 
would be given in marriage to the slowest horse in a race among her suitors. In 
order to prevent the race from taking all day, he randomly assigned each suitor 
to ride a different suitor's horse.

In regular go, rich men (winners) don't pick fights; losers do.

In Hahn go, rich men pick fights, and losers seek to minimize their losses. 

I'd love to see a regular Hahn tournament among computer programs; it might 
lead to some interesting advances. Strong programs might become rapaciously 
bloodthirsty daredevils. They might develop models of opponents' weaknesses - 
learning that programs A and B always fall for certain swindles, but C and D do 
not. 


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Hahn system tournament and MC bots

[terry mcintyre]

In my experience, go players (I include myself) rarely count territory until 
they reach the low-kyu level.

It's all about slaying dragons and adventure.

Terry McIntyre terrymcint...@yahoo.com


Anarchism is founded on the observation that since few men are wise enough to 
rule themselves, even fewer are wise enough to rule others. - Edward Abbey


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: Hahn system tournament and MC bots

[terry mcintyre]

Perhaps computers play better (so far) when they focus on the wins because they 
are not omniscient; they can get suckered into thinking that large groups are 
alive or dead when the reverse is actually true. Humans are better at 
chunking life-and-death status of independent groups.

( Newell and Simon, Cognitive Science, Chunking hierarchies )

http://en.wikipedia.org/wiki/Chunking_%28psychology%29


Terry McIntyre terrymcint...@yahoo.com


Anarchism is founded on the observation that since few men are wise enough to 
rule themselves, even fewer are wise enough to rule others. - Edward Abbey




From: Don Dailey dailey@gmail.com
To: computer-go computer-go@computer-go.org
Sent: Mon, November 23, 2009 8:21:15 AM
Subject: Re: [computer-go] Re: Hahn system tournament and MC bots

I have repeatedly stated that the Hahn system is a simplification,  but this is 
just a guess on my part and I might have it backwards.I'm not sure whether 
that invalidates the idea that computers will play this better or not.

Here is a thought experiment.Imagine an omniscient  player or program which 
is capable of always playing the very best move according to either criteria 
that you configure.You can configure it maximize the score, or to win the 
game. 

In win game mode it will play ANY move randomly that is good enough.   Since 
it is omnicient there is no point in talking about risk,  or chances in any 
context. In a lost game it would play a move at random.

In maximize score mode it would choose the move that maximizes the total points 
taken on the board.  It would be the perfect Hahn system player for instance.   

The more difficult strategy is to maximize total points on the board.In 
fact, this is a superset of the other strategy because maximizing the points 
taken will always be a valid way to implement the try to win game strategy,  
but the reverse is not true.

This is no doubt why computers play stronger with the goal to win the game - it 
is a much less distracting concept for a computer to grasp.

So I am not sure, but I might be reversing my point of view on this.I have 
to think about it some more.   It's clear that computers play weaker with this 
strategy, but I'm still pretty sure they will play the Hahn system better with 
the maximize points taken strategy but it may not follow that they will play 
this better relative to humans.Especially if it is a more challenging goal. 
What I cannot decide is if it is really more challenging - I just know it's 
more challenging to do it perfectly.   

- Don








On Mon, Nov 23, 2009 at 11:00 AM, Robert Jasiek jas...@snafu.de wrote:

steve uurtamo wrote:

the idea that i like about keeping track of number of points won or
lost by is that not only could you find the winner, but you could find
how absolutely dominant, on average, they were against their
opponents.


Under normal Go: no! E.g., some players have the style to let every game be 
close.

-- 

robert jasiek
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/




  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: Hahn system tournament and MC bots

[terry mcintyre]

see http://senseis.xmp.net/?BangNeki

 Terry McIntyre terrymcint...@yahoo.com


Anarchism is founded on the observation that since few men are wise enough to 
rule themselves, even fewer are wise enough to rule others. - Edward Abbey


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Shodan Go Bet: Nov '09 Update

[terry mcintyre]

Any hardware which can be brought to the playing site would presumably 
include today's baby supers, which include a few dozen cores in a desktop box. 

Would it include whatever fits into Sun's datacenter-in-a-shipping-container?


I am less optimistic about the computer's prospects now than I was two years 
ago. 
 
Terry McIntyre terrymcint...@yahoo.com


Anarchism is founded on the observation that since few men are wise enough to 
rule themselves, even fewer are wise enough to rule others. - Edward Abbey


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Elo move prediction

[terry mcintyre]

It may be helpful to incrementally compute information on a move-by-move basis, 
rather than recompute for all points on the board. 

For example; if you choose to store the liberties of groups, and a single stone 
is placed on the board, it affects only those strings which have thereby lost a 
liberty. It may lead to combining two or more strings. It may also lead to a 
capture, which creates liberties -- but captures are much less frequent than 
non-capturing moves, so it pays to optimize the non-capturing move heavily.


Similar approaches may work for whatever else is being measured. If one stone 
is played at a time, what does this change? Recomputing anything 361 times for 
each move of each playout is likely to be sluggish.

Terry McIntyre terrymcint...@yahoo.com


Anarchism is founded on the observation that since few men are wise enough to 
rule themselves, even fewer are wise enough to rule others. - Edward Abbey


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Go Programming Language

[terry mcintyre]

Perhaps it is time to switch to the Korean name, baduk?

 Terry McIntyre terrymcint...@yahoo.com


Anarchism is founded on the observation that since few men are wise enough to 
rule themselves, even fewer are wise enough to rule others. - Edward Abbey





From: Michael Williams michaelwilliam...@gmail.com
To: computer-go computer-go@computer-go.org
Sent: Wed, November 11, 2009 3:49:46 PM
Subject: Re: [computer-go] Go Programming Language

If you thought finding Go(game)-related stuff on the web was hard before...


Ben Shoemaker wrote:
 Has anyone tried programming Go in the Go Programming Language?
 
 http://golang.org/
 
 
 
   ___
 computer-go mailing list
 computer-go@computer-go.org
 http://www.computer-go.org/mailman/listinfo/computer-go/
 

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: Joseki Book

[terry mcintyre]

Robert,

Your post is the first usage of sum-style that I have seen -- and I haven't 
turned up anything at senseis.xmp.net. 

What is sum-style? Can you elucidate? Do I have to read the book?

Thanks!

 Terry McIntyre terrymcint...@yahoo.com


Anarchism is founded on the observation that since few men are wise enough to 
rule themselves, even fewer are wise enough to rule others. - Edward Abbey





From: Robert Jasiek jas...@snafu.de
To: computer-go computer-go@computer-go.org
Sent: Tue, November 10, 2009 1:04:12 PM
Subject: Re: [computer-go] Re: Joseki Book

Ingo Althöfer wrote:
 ... I do not mention some obvious mistakes.
 Are they later in the game(s), or also
 some in the openings?

Also some during the opening. (Every dan player can point them out to you. Ask 
those that can distinguish sum-style from obvious mistakes.)

-- robert jasiek
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: Joseki Book

[terry mcintyre]

When building a joseki database, there is a caveat which may not be obvious to 
kyu-level players:

Some joseki sequences depend upon ladder relationships. 

When the ladder succeeds, the joseki move may be brilliant. When the ladder 
fails, the same sequence leads to disaster. 

Smart opponents will pick the sequence which leads to disaster for you, if you 
give them a chance.

MCTS may not detect such sequences, since they often require very precise order 
of play.



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [SPAM] Re: [computer-go] Joseki Book

[terry mcintyre]

One approach might be to combine some well-known joseki and fuseki books with 
such books as 100 tips for Amateur Players, which explain some of the 
pitfalls, tricks, and traps behind popular joseki. Nihon Kiin publishes some 
detailed and thorough joseki books.

Slate and Shell published a series of workbooks by Yilun Yang; one of those 
suggests a few guidelines for when to tenuki, that is, when it is ok for one 
to ignore an approach move and play elsewhere. These might help guide a program 
to know when to stay on the main line of a joseki, and when to switch to 
another important point.

There is a proverb, study joseki, lose two stones.(in strength) I don't know 
if anybody has used MCTS to blend local joseki knowledge with strategic 
knowledge to determine which joseki is most appropriate; that might be an 
interesting line of approach. If you store the joseki as a tree, it might make 
sense to expand not just one, but the several main lines in the tree, then 
compare their merits. One might even expand the trick play lines.

I once was told by a Japanese Go professional that he was given two very strict 
commands when he began studying as an insei. The first was, never, ever study 
joseki. The second was, never ever play his father. ( who was a 3 P 
professional ).


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Joseki Book

[terry mcintyre]

From: Alain Baeckeroot alain.baecker...@laposte.net

Le 09/11/2009 à 08:04, Jessica Mullins a écrit :
 
 Hi,
 
 I am wondering what is the best way to build a Joseki Book? I am a student at
 Lewis  Clark College and am working with Professor Peter Drake to build a
 Joseki Book for the program Orego.
 
 Right now I am extracting moves from professor players and saving those into a
 database. Then if during game play a position is contained in the database,
 play the response move like the professional. I am just wondering what other
 people have done to build a Joseki Book, or if anyone knows of any papers that
 might be helpful.
 

I don't knwo how to build such a book, but
Kogo's Joseki dictionnary is a huge .sgf file containging joseki + trick
moves and punishment. Maybe it can be parsed to extract only joskis.

I have been told by stronger players that Kogo, while a useful starting point, 
needs to be supplemented with newer lines of play.

Regarding automatic extraction of joseki from pro games - the one pitfall I see 
is that you'll only discover the surface of a much deeper tree of moves which 
don't appear in pro games - how best to respond to non-joseki plays. A move is 
joseki because sound refutations to non-joseki plays exist, but those 
refutations can be subtle; a characteristic of a trick play is that the 
refutation is difficult for weaker players.


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [SPAM] Re: [computer-go] First ever win of a computer against a pro 9P as black (game of Go, 9x9).

[terry mcintyre]

That sounds to me like a dumb human with a smart algorithm can beat a fast 
computer with a dumb algorithm -- which speaks more to Penrose's reluctance to 
improve algorithms in his dumbed-down computer models than it does to any 
quantum-physical effects. 

 
Stir in some theorem-proving ability - where a great deal of research was 
accomplished decades ago - and a computer chess program can prove theorems 
about chess positions, including these bishops can never get past these pawns.

This may be useful in computer Go. One of the reasons human pros do well is 
that they compute certain sub-problems once, and don't repeat the effort until 
something important changes. They know in an instant that certain positions are 
live or dead or seki; they know when a move ( reducing a liberty, for example ) 
disturbs that result. This could probably be emulated with theorem-proving 
ability. Presently, search algorithms have to rediscover these results many 
times over; this is (in my opinion) why computer programs get significantly 
weaker when starved for time; they cannot think deeply enough to solve problems 
which may be solved in an eyeblink by a pro.

I've observed some high-dan-level amateurs playing complex semeai on 19x19 
games. They might not actually know the result of a semeai, but they  respond 
quickly to moves which would alter the status - if one of my liberties is 
taken, I take one of his - until such point as the player takes a noticeably 
long time to re-analyse the semeai and think I need not respond to that move 
and takes sente. The stronger the player, the more accurate these assessments 
are. 

Terry McIntyre terrymcint...@yahoo.com


And one sad servitude alike denotes
The slave that labours and the slave that votes -- Peter Pindar




From: Mark Boon tesujisoftw...@gmail.com
To: computer-go computer-go@computer-go.org
Sent: Thu, October 29, 2009 10:14:18 AM
Subject: Re: [SPAM] Re: [computer-go] First ever win of a computer against a 
pro 9P as black (game of Go, 9x9).

Roger Penrose thinks the human brain can do things a Turing machine cannot. 
(Note: I don't say 'computer'.) He claims it's due to some quantum-physical 
effects used by the brain. I doubt his ideas are correct, but he did have a few 
interesting chess-positions to support his theory. Typically, they would 
contain a completely locked position, say a V-shaped pawn position and bishops 
on the wrong color to pass the pawn-ranks. These types of positions are very 
easily analyzed by even mediocre players, yet a computer never gets the right 
answer.

Basically what it shows is that the human brain is able to conceptualize 
certain things that enable it to reason about situations that cannot be 
calculated by brute force. I don't claim that a Turing machine cannot do such 
things as well if programmed well, but it's very easy to see that there could 
be barriers to computers, no matter how much computing power you give them, if 
they solely rely on a simple method with brute force.

Mark
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Congratulations to AyaMC!

[terry mcintyre]

Is there a way to implement I don't understand that command? a NAK, perhaps?

 Terry McIntyre terrymcint...@yahoo.com


And one sad servitude alike denotes
The slave that labours and the slave that votes -- Peter Pindar





From: Nick Wedd n...@maproom.co.uk
To: computer-go computer-go@computer-go.org
Sent: Tue, October 6, 2009 9:13:17 AM
Subject: Re: [computer-go] Congratulations to AyaMC!

In message wladvtgcx1ykf...@maproom.demon.co.uk, Nick Wedd 
n...@maproom.co.uk writes
 Congratulations to AyaMC, winner of Sunday's KGS Computer Go tournament! My 
 report is at
 http://www.weddslist.com/kgs/past/52/index.html
 
 Two people had bots crash after receiving the message
 FINEST: Still an outstanding command.  I do not know what this means, and 
 am reporting it to wms.

I have heard back from wms:

 The still an outstanding command message means that a
 command has been sent to the engine, but the engine hasn't yet
 answered it. That's probably a bug in the engine, because GTP
 requires all commands to be answered with an acknowledgement
 or an error.

So it seems that CzechBot (=MoGo) and Fuego need to implement something, I 
don't know what.  It's strange that this has never come up before.

Nick
-- Nick Weddn...@maproom.co.uk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Generalizing RAVE

[terry mcintyre]

From: Brian Sheppard sheppar...@aol.com

 I have another way to fail to improve on RAVE. :-)

Well, that's great news. 

Thomas Edison was once asked if he felt discouraged by 10 thousand failed 
experiments, and he said Not at all; I now know ten thousand ways to not build 
an electric light bulb.


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Generalizing RAVE

[terry mcintyre]

Peter Drake wrote:
The more I study this and try different variants, the more impressed I  
am by RAVE. Boards after the current board is a very clever way of  
defining similarity. Also, recorded RAVE playouts, being stored in  
each node, expire in an elegant way. It still seems that RAVE fails to  
exploit some sibling information. For example, if I start a playout  
with black A, white B, and white wins, I should (weakly) consider B as  
a response to any black first move.

Yamato replied:

 It is exactly the same as my thought. I also have tried CRAVE, but the
 results were worse than normal RAVE.

 While RAVE is a very efficient algorithm, it strongly limits scalability
 of the program. It typically makes a fatal mistake in the position that
 the order of moves are important. We definitely need to improve RAVE,
 but it is a very tough job.

Indeed it is. How may a program reason about the order of moves? At higher 
levels of play, the order of moves is often crucial. 


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Dead stones in human-bot games

[terry mcintyre]

Is there no way for the bot to dispute the other player's decision? 

I recall something of the sort in human-to-human play -- both have to agree 
before the scoring phase.

I do not know whether the KGS API works the same way.

 Terry McIntyre terrymcint...@yahoo.com
And one sad servitude alike denotes
The slave that labours and the slave that votes -- Peter Pindar





From: Peter Drake dr...@lclark.edu
To: Computer Go computer-go@computer-go.org
Sent: Thursday, September 17, 2009 1:52:07 PM
Subject: [computer-go] Dead stones in human-bot games

Orego has been doing well in 9x9 games on KGS, using the fast time controls of 
this weekend's upcoming tournament. I even improved the endgame behavior a bit: 
Orego will pass if (a) the opponent has passed first, and (b) after removing 
Orego's dead stones, but not the opponent's, Orego still wins. This means that 
Orego won't always play until there are no legal moves.

I looked at one of the lost games (attached), and found that (if I'm reading 
this correctly) the human won simply by marking all of Orego's (white) stones 
dead. Do bots automatically defer to humans when there are disputes? Isn't 
there supposed to be a cleanup phase? Would it be the same in a rated game?




Peter Drake
http://www.lclark.edu/~drake/


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] any mac programmers out there?

[terry mcintyre]

Cool! Have you had a chance to experiment with the gcc-llvm and clang versions 
of fuego?

 



From: David Doshay ddos...@mac.com

The best way to do it is to use darwinports to install the boos libs. That 
means installing the ports infrastructure first and using it to install boost. 
I just finished doing it last week and Fuego compiles on my Mac laptop.

Cheers,
David

On 7, Sep 2009, at 11:17 PM, Mark Boon wrote:

 Just being curious I decided to give it a swing to see if Fuego would compile 
 on a Mac. The configure scripts stops saying 'boost' is not installed. So I 
 downloaded the latest version of that (it's huge!) and set a BOOST_ROOT 
 environment variable, but it still says it can't find it.
 
 Anyone know what's the matter there? I must admit I didn't spend a whole lot 
 of time trying to figure it out.
 
 Mark
 
 ___
 computer-go mailing list
 computer-go@computer-go.org
 http://www.computer-go.org/mailman/listinfo/computer-go/

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] any mac programmers out there?

[terry mcintyre]

Found an interesting article on Snow Leopard at Ars Technica ... 20-some pages.

http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars

Of interest to Computer Go programmers: the addition of blocks to C, which 
allow closures and other fun stuff, much like Lisp. LLVM, which allows JIT 
compilation to multiple architectures, including GPUs; Grand Central Dispatch, 
which provides very light-weight concurrency; and CLANG, a new compiler which 
is said to be quite an improvement over GCC. Open CL, which leverages LLVM to 
program GPUs.

 Terry McIntyre terrymcint...@yahoo.com
And one sad servitude alike denotes
The slave that labours and the slave that votes -- Peter Pindar



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] any mac programmers out there?

[terry mcintyre]

From: Jason House jason.james.ho...@gmail.com


On Sep 5, 2009, at 10:41 AM, terry mcintyre terrymcint...@yahoo.com wrote:

Found an interesting article on Snow Leopard at Ars Technica ... 20-some pages.

http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars

Of interest to Computer Go programmers: the addition of blocks to C, which 
allow closures and other fun stuff, much like Lisp. 


D and C# are other C-family languages with similar.


LLVM, which allows JIT compilation to multiple architectures, including GPUs; 
Grand Central Dispatch, which provides very light-weight concurrency; and 
CLANG, a new compiler which is said to be quite an improvement over GCC. 

Łukasz reported a 15% performance drop for libego when moving from gcc to llvm.

llvm is under heavy development; it has probably improved since. Also, any new 
technology has both strong and weak points; it takes time to learn how to 
optimally fit an algorithm to a compiler. Apple reports that recent versions of 
llvm outperform gcc.


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] MoGo policy: capture stones anywhere?

[terry mcintyre]

If you maintain a list of strings ( connected groups ) of stones and their 
liberty counts - or perhaps the actual liberties - it should be fairly quick to 
find a string with just one liberty.  In any case, if I read the explanation 
correctly, this happens infrequently, if several less-expensive tests fail; the 
cost would be amortized over many trials.

 Terry McIntyre terrymcint...@yahoo.com
And one sad servitude alike denotes
The slave that labours and the slave that votes -- Peter Pindar





From: Peter Drake dr...@lclark.edu
To: Computer Go computer-go@computer-go.org
Sent: Monday, August 31, 2009 9:56:16 PM
Subject: [computer-go] MoGo policy: capture stones anywhere?

MoGo's playout policy (at one time) is given in section 3.2 of Gelly et al's 
paper, Modification of UCT with Patterns in Monte-Carlo Go:

We describe briefly how the improved random mode generates moves. It first 
verifies
whether the last played move is an Atari; if yes, and if the stones under Atari 
can be saved
(in the sense that it can be saved by capturing stones or increasing 
liberties), it chooses one
saving move randomly; otherwise it looks for interesting moves in the 8 
positions around the
last played move and plays one randomly if there is any; otherwise it looks for 
the moves
capturing stones on the Go board, plays one if there is any. At last, if still 
no move is
found, it plays one move randomly on the Go board.

We've implemented much of this, which has made Orego considerably stronger. The 
problem is with this part:

otherwise it looks for the moves capturing stones on the Go board

Does this really mean traversing the entire board looking for captures? Doing 
so seems to create a catastrophic speed hit.

Peter Drake
http://www.lclark.edu/~drake/



___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] congrats to Fuego! from US Go email

[terry mcintyre]

FUEGO BEATS PRO IN 9X9 EVEN GAME: The
Fuego computer go program won a 9x9 even game against 9-dan
professional Chou Chun-Hsun (Zhou Junxun, left) at the Human vs.
Computer Program Competition (FUZZ-IEEE 2009) event held August 21-22
on Jeju Island, Korea. Fuego played three official games
with Zhou, winning the first - taking white -- by 2.5 points. This is
the first time that a computer program has won a 9x9 game on even
against a top-ranked player. Everybody considers the win of Fuego in
9x9 as very good, said Olivier Teytaud, leader of the MoGo team. No
error from the pro, just a perfect play by the computer. Click here for
the game record. The Fuego team includes Markus Enzenberger, Broderick
Arneson, Rich Segal (IBM) and Gerry Tesauro (IBM). The Japanese program
Zen also put in a very strong performance, beating amateur Chang
Shen-Su 6d with both Black and White on 9x9. The other two computer
participants, MoGo and Many Faces of Go, did not win any games; click here for
full results. I would like to thank everyone who helped, says Martin
Mueller, especially Steve Sutphen for getting Fuego set up on the
cluster, and Jonathan Schaeffer for financial support, and for allowing
us to use his machine with its 80 cores. - photo of Chou Chun-Hsun by Jimmy Lin
 Terry McIntyre terrymcint...@yahoo.com
And one sad servitude alike denotes
The slave that labours and the slave that votes -- Peter Pindar



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Dynamic komi at high handicaps

[terry mcintyre]

Consider the game when computer is black, with 7 stones against a very strong 
human opponent.

Computer thinks every move is a winning move; it plays randomly; a half-point 
win is as good as a 70-point win. 

Pro gains ground as computer makes slack moves, taking slightly less than its 
full due. 

At some point, the computer, being the weaker player, makes one slack move 
too many and loses the game.

Rinse and repeat.

At some point, it dawns on the programmer: must attack to win handicap games. 
Must be a little bit greedy, to slow down the process of attrition.

Dynamic komi models something real: the significant advantage of the computer 
in a handicap game. It tries to preserve as much of that advantage as possible.

I don't know if it will work for computer vs human games.

I do know that a similar idea helped me defeat a human player and reduce my 
handicap by 3 stones. Not having the patience for thousands of 30-minute games 
to achieve statistically valid results, I settled for trouncing my opponent 
three games in a row by a large margin, then doing it again with a smaller 
handicap for three more games. I can't win by 70 stones in a 7 stone game, but 
20 or 30 was enough to prove my point. If I made random plays under the 
assumption that I still had a half-point win, my opponent's predictive powers 
would be superior to mine - that's why he gives me a handicap and not vice 
versa.

 
I can't really be sure that my prediction of a 22.5 point win is exact to the 
last decimal point - but if it should be within 5 or 10 or even 20, I'm 
perfectly happy.

It's nice that statistics of a series of one-bit values are so useful, but when 
a significant fraction of those one-bit values are 100% wrong, that introduces 
a bit of noise to one's estimates. One hopes that they balance evenly, but 
perhaps they do not. 

Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop





From: Don Dailey dailey@gmail.com
To: computer-go computer-go@computer-go.org
Sent: Wednesday, August 19, 2009 6:03:50 AM
Subject: Re: [computer-go] Dynamic komi at high handicaps

One must decide if the goal is to improve the program or to improve it's 
playing behavior when it's in a dead won or dead lost positions. 

It's my belief that you can probably cannot improve the playing strength soley 
with komi manipulation,  but at a slight decrease in playing strength you can 
probably improve the behavior, as measured by a willingness to fight for space 
that is technically not relevant to the goal of winning the game.And only 
then if this is done carefully.  However I believe there are better ways,  
such a pre-ordering the moves.   

Even if this can prove to be a gain,  you are really working very hard to find 
something that only kicks in when the game is already decided - how to play 
when the game is already won or already lost.But only the case when the 
game is lost is this very interesting from the standpoint of making the program 
stronger.

And even this case is not THAT interesting, because if you are losing, on 
average you are losing to stronger players.   So you are working hard on an 
algorithm to beat stronger players when you are in a dead lost game?   How much 
sense does that make?   

So the only realistic pay-off here is how to salvage lost games against players 
that are relatively close in strength since you can expect not to be in this 
situation very often agaist really weak players.So you are hoping to 
bamboozle players who are not not weaker than you - in situations where you 
have been bamboozled (since you are losing,  you are the one being outplayed.)  
 

That is why I believe that at best you are looking at only a very minor 
improvement.If I were working on this problem I would be focused only on 
the playing style,  not the playing strength.   

If you want more than the most minor playing strength improvement out of this 
algorithm, you have to start using it BEFORE the loss is clear,  but then you 
are no longer playing for the win when you lower your goals,  you are playing 
for the loss.  

- Don





2009/8/19 Stefan Kaitschick stefan.kaitsch...@hamburg.de

One last rumination on dynamic komi:
 
The main objection against introducing dynamic komi 
is that it ignores the true goal
of winning by half a point. The power of the 
win/loss step function as scoring function underscores
the validity of this 
critique. And yet, the current behaviour of mc bots, when either leading or 
trailing by a large margin, resembles random play.
The simple reason for this 
is that either every move is a win or every move is a loss.
So from the 
perspective of securing a win, every move is as good as any other 
move.
Humans know how to handle these situations. They try to catch up from 
behind, or try to play safely while defending enough of a winning margin.
For 
a bot

Re: [computer-go] Erlang and computer go

[terry mcintyre]

Peter Drake, I know Orego was written in Java. How do you handle memory 
allocation? Is there an equivalent of the C method of pre-allocating a large 
chunk and managing the nodes internally, instead of billions of alloc/free 
cycles?

 Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop





From: Don Dailey dailey@gmail.com
To: computer-go computer-go@computer-go.org
Sent: Friday, August 14, 2009 2:25:06 PM
Subject: Re: [computer-go] Erlang and computer go

I don't think JVM performance will be an issue for this.I assumed that you 
were willing to sacrifice a small amount of speed for a high level prototyping 
language and I think you will only get about 20-30% slowdown over C - I'm 
judging this by the performance of the reference bots I did in both java and C. 


You are probably not going to get any closer than this with any other high 
level language.

If you like lispy languages there is something called bitc which is supposed 
to be pretty close to C in speed and there is also D, which has the potential 
to be faster than C - although it isn't right now.D would probably be a 
little closer to C speed than Java or Scala.

My issue with Java and JVM is the memory hog nature and pathetic startup times 
- which make it FEEL slow and unresponsive, but in actuality it is pretty fast. 
   I have found that java doesn't play well with memory - I would not use Java 
(or Scala) if you plan to do the big memory thing with MCTS, which likes 
efficient memory management and lots of space for nodes.   

But I cannot say for sure that this won't work.   I don't understand Java 
enough and maybe there are data structures that you can preallocate in unboxed 
fashion that will be efficient.But my sense of things is that a node is 
going to be pretty fat.  

Honestly, I think your decision to stay with C is likely to be best.   I don't 
even consider anything else when I look at a project that I think is going to 
need serious performance and memory requirements.  

- Don





On Fri, Aug 14, 2009 at 5:07 PM, Carter Cheng carter_ch...@yahoo.com wrote:

Thanks both I guess I will stick with C/C++ for now. I have looked at Scala 
before though not in this particular context. It looks like a pretty 
compelling language with some pretty nice features (true lambda functions, 
argument pattern matching among others). JVM performance does concern me 
however.

I do have a followup question but I will make a separate topic of it.

--- On Fri, 8/14/09, Vlad Dumitrescu vladd...@gmail.com wrote:

 From: Vlad Dumitrescu vladd...@gmail.com
 Subject: Re: [computer-go] Erlang and computer go
 To: computer-go computer-go@computer-go.org
 Date: Friday, August 14, 2009, 1:56 PM

 On Fri, Aug 14, 2009 at 22:16, Carter
 Chengcarter_ch...@yahoo.com
 wrote:
  I have been considering experimenting with Erlang as a
 means of prototyping certain aspects of a computer go
 program and I was curious if anyone has tried this already.
 How does a system like Erlang compare performance wise to
 writing something in say C/C++ (fastest) or Java?

 Hi,

 I have started for some year ago to try to withe an Erlang
 library to
 play go, but got distracted by other stuff.

 Erlang has a lot of nice features, but in this particular
 instance
 speed isn't one of them. The main issue is that there are
 no mutable
 data structures, so for all processing there will be a lot
 of copying.
 This is somewhat simplified, of course, but the conclusion
 still
 holds. I don't have any hard numbers, it would depend very
 much upon
 the choice of data structure.

 Erlang would be good at coordinating work done by simple
 and fast
 slaves, written in C for example. It would be very
 appropriate for a
 distributed engine. The problem here is that the problem
 of
 synchronizing a distributed UCT tree hasn't been solvet
 yet, to my
 knowledge.

 regards,
 Vlad
 ___
 computer-go mailing list
 computer-go@computer-go.org
 http://www.computer-go.org/mailman/listinfo/computer-go/




___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/




  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Dynamic komi at high handicaps

[terry mcintyre]

One reason dynamic komi seems a bit odd is that the numbers are pulled out of 
thin air. Why should the komi be X instead of Y? When should the value be 
changed?

Going back to the original thought experiment: the komi at the start of the 
game should reflect the expert assessment of how far ahead black is compared to 
white. 

A rational program should periodically change that assessment, as black 
blunders through the game.

So, my next question is, what sort of experimentation has been done to assess 
the likely score at various parts of the game? Any results?

It seems natural that a strong player, looking at a lot of handicap stones, 
will recognize that the position against an equally strong player would entail 
a loss - but of about n*10 stones, not of n*20 stones - and set an interim goal 
to acquire that much, while leaving opportunities for black to fumble. As such 
fumbles occur, white opportunistically consolidates more territory, and 
expectations are adjusted upwards -- only a 40 point loss now ... only 10 
points now ... striking distance ... black is torpedoed now!



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Dynamic komi at high handicaps

[terry mcintyre]

The dynamic komi is perhaps a misnomer; it's by accident that changing komi 
reflects something which we do want to measure, namely the predicted score. 

An algorithm which does not make use of the predicted score would not make use 
of all available information. 

On a 19x19 board, it is common for some areas to become settled; whether 
unconditionally alive, or ( more likely ) alive under the assumption of 
alternating play. Many moves trade the prospect of territory here versus there. 
Bad moves give up too much for too little. Good moves exploit bad or slack 
moves, and provide an equitable balance against good play.

 Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop





From: Don Dailey dailey@gmail.com
To: computer-go computer-go@computer-go.org
Sent: Thursday, August 13, 2009 9:27:11 AM
Subject: Re: [computer-go] Dynamic komi at high handicaps




2009/8/13 Stefan Kaitschick stefan.kaitsch...@hamburg.de

Modeling the opponents mistakes is indeed an 
alternative to introducing komi.
But it would have to be a lot more exact than 
simply rolling the dice or skipping a move here and there.
Successful opponent modeling would implement the 
overplay school of thought - playing tactically refutable
combinations that are beyond the opponents skill to 
punish them.

I cannot believe you are being so technically precise about doing this 
correctly while advocating something on the other hand which is so obviously 
incorrect.

You probably have something here though.I think the play-out policy is a 
more fruitful area to explore than dynamically changing komi.   

I would start simple, just trying the simplest approach first then gradually 
refining it.   Random occasional pass moves is certainly easy to implement as a 
first step.

- Don


 
Introducing komi at the 50% win rate level would 
implement the honte school of thought - play as if against 
yourself.
At a win rate of less than 50% it implements the 
almost honte school of thought. :-)
I'm not trying to moralize. In love and go anything 
is fair.
I'm just saying that while both approaches are 
legitimate, adjusting the komi is much easier to do.
 
Different subject, suggestion for a komi adjustment 
scheme:
 
1. Make a regular evaluation(no extra 
komi)
2. If the win rate of the best move is within 
certain bounds you're done
(Say between 30 and 70 percent.Just a 
guess ofcourse.Also, this might shift as the game progresses)
3. If not, make a komi adjustment dependant on how 
far out of bounds the win rate is.
(No numerical suggestion here. Please 
experiment.)
4. Make a new search with this komi.
5. If the new result is in bounds calculate 
winrate_nokomi * factor + winrate_komi for each candidate and choose the 
highest 
one.
(factor around 10 maybe)
6. If not, go back to 3
 
 
The idea is to choose a move that doesnt contradict 
the long term goal(no komi search) while trying for a short term goal(komi 
search)
if no long term goal is available.( Or if every 
move satisfies the long term goal in case of taking handicap)
  
Stefan
 
 
 
- Original Message - 
From: Don 
  Dailey 
To: tapani.ra...@tkk.fi ; computer-go 
Sent: Thursday, August 13, 2009 4:02 
  PM
Subject: Re: [computer-go] Dynamic komi 
  at high handicaps


This idea makes much more sense to me than adjusting komi 
  does.At least it's an attempt at opponent modeling, which 
  is the actual problem that should be addressed. 
  Whether it will actually work is something that could be 
  tested.

Another similar idea is not to pass but to play some percentage 
  of random moves - which probably would work in programs with strong playout 
  strategies.   Of course this would be meaningless for bots that have 
  weak (and already random) playout strategies.

- Don





On Thu, Aug 13, 2009 at 6:17 AM, Tapani Raiko pra...@cis.hut.fi wrote:

I don't think the komi should be 
adjusted.

Instead:

Wouldn't random passing by black during the 
playouts model black making
mistakes much more accurately? The number of 
random passes should be
adjusted such that the playouts are close to 
50/50. Adjusting the komi
would make black play greedily, while random 
passing during playouts
would make black play safe (rich men don't pick 
fights).

Tapani Raiko


Christoph Birk wrote:

 I think you got it 
the wrong way round.
 Without dynamic komi (in high ha
 ndicap 
games) even trillions of simulations
 with _not_ find a move that 
creates a winning line, because the is none,
 if the opponet has the 
same strength as you.
 WHITE has to assume that BLACK will make 
mistakes, otherwise there
 would be no handicap.

 
Christoph
 ___
 
computer-go mailing list
 computer-go@computer-go.org
 
 http://www.computer-go.org/mailman/listinfo/computer-go/


--
 Tapani Raiko, tapani.ra

Re: [computer-go] Dynamic komi at high handicaps

[terry mcintyre]

I have never heard a pro say I estimate my chances of winning this game to be 
50.3%, but you will hear black is ahead by 3 points or white wins by 1/2 
point. -- they'll make this evaluation based on the alternation of equally 
competent play. 


 Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop





From: Don Dailey dailey@gmail.com
To: computer-go computer-go@computer-go.org
Sent: Thursday, August 13, 2009 10:20:58 AM
Subject: Re: [computer-go] Dynamic komi at high handicaps




2009/8/13 terry mcintyre terrymcint...@yahoo.com

The dynamic komi is perhaps a misnomer; it's by accident that changing komi 
reflects something which we do want to measure, namely the predicted score. 

An algorithm which does not make use of the predicted score would not make use 
of all available information. 

You imply that it's some kind of travesty not to make use of available 
information, but the information is only available because you did extra work 
to generate it. And even if the information was free,  it matters that you 
use it correctly.  Just implying that it's wrong not to do this because you 
are throwing away available information is not going to cut it.  



 


On a 19x19 board, it is common for some areas to become settled; whether 
unconditionally alive, or ( more likely ) alive under the assumption of 
alternating play. Many moves trade the prospect of territory here versus 
there. Bad moves give up too much for too little. Good moves exploit bad or 
slack moves, and provide an equitable balance against good play.

I think you have describe very well why dynamic komi is so hard.   You take ALL 
these factors and ignore them all except for a single number.   You don't know 
anything about the composition of that number.If your concern is about 
throwing away infromation, then dynamic komi should be a big problem for you.



- Don


 


 Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” --
 Aesop






From: Don Dailey dailey@gmail.com
To: computer-go computer-go@computer-go.org
Sent: Thursday, August 13, 2009 9:27:11 AM

Subject: Re: [computer-go] Dynamic komi at high handicaps





2009/8/13 Stefan Kaitschick stefan.kaitsch...@hamburg.de

Modeling the opponents mistakes is indeed an 
alternative to introducing komi.
But it would have to be a lot more exact than 
simply rolling the dice or skipping a move here and there.
Successful opponent modeling would implement the 
overplay school of thought - playing tactically refutable
combinations that are beyond the opponents skill to 
punish them.

I cannot believe you are being so technically precise about doing this 
correctly while advocating something on the other hand which is so obviously 
incorrect.

You probably have something here though.I think the play-out policy is a 
more fruitful area to explore than dynamically changing komi.   

I would start simple, just trying the simplest approach first then gradually 
refining it.   Random occasional pass moves is certainly easy to implement as 
a first step.

- Don


 
Introducing komi at the 50% win rate level would 
implement the honte school of thought - play as if against 
yourself.
At a win rate of less than 50% it implements the 
almost honte school of thought. :-)
I'm not trying to moralize. In love and go anything 
is fair.
I'm just saying that while both approaches are 
legitimate, adjusting the komi is much easier to do.
 
Different subject, suggestion for a komi adjustment 
scheme:
 
1. Make a regular evaluation(no extra 
komi)
2. If the win rate of the best move is within 
certain bounds you're done
(Say between 30 and 70 percent.Just a 
guess ofcourse.Also, this might shift as the game progresses)
3. If not, make a komi adjustment dependant on how 
far out of bounds the win rate is.
(No numerical suggestion here. Please 
experiment.)
4. Make a new search with this komi.
5. If the new result is in bounds calculate 
winrate_nokomi * factor + winrate_komi for each candidate and choose the 
highest 
one.
(factor around 10 maybe)
6. If not, go back to 3
 
 
The idea is to choose a move that doesnt contradict 
the long term goal(no komi search) while trying for a short term goal(komi 
search)
if no long term goal is available.( Or if every 
move satisfies the long term goal in case of taking handicap)
  
Stefan
 
 
 
- Original Message - 
From: Don 
  Dailey 
To: tapani.ra...@tkk.fi ; computer-go 
Sent: Thursday, August 13, 2009 4:02 
  PM
Subject: Re: [computer-go] Dynamic komi 
  at high handicaps


This idea makes much more sense to me than adjusting komi 
  does.At least it's an attempt at opponent modeling, which 
  is the actual problem that should be addressed. 
  Whether it will actually work is something that could be 
  tested.

Another similar idea

Re: [computer-go] Dynamic komi at high handicaps

[terry mcintyre]

Ingo suggested something interesting - instead of changing the komi according 
to the move number, or some other fixed schedule, it varies according to the 
estimated winrate. 

It also, implicitly, depends on one's guess of the ability of the opponent. 

An interesting test would be to take an opponent known to be weaker, offer it a 
handicap, and tweak the dynamic komi per Ingo's suggestion. At what handicap 
does the ratio balance at 50:50? Can the number of handicap stones be increased 
with such an adaptive algorithm?

Even better, play against a stronger opponent; can one increase the win rate 
versus strong opponents?

The usual range of computer opponents is fairly narrow. None approach high-dan 
levels on 19x19 boards - yet.

 Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop




From: Brian Sheppard sheppar...@aol.com
To: computer-go@computer-go.org
Sent: Wednesday, August 12, 2009 12:33:13 PM
Subject: [computer-go] Dynamic komi at high handicaps

The small samples is probably the least of the problems with this.   Do you
actually believe that you can play games against it and not be subjective
in
your observations or how you play against it?

These are computer-vs-computer games. Ingo is manually transferring moves
between two computer opponents.

The result does support Ingo's belief that dynamic Komi will help programs
play high handicap games. Due to small sample size it isn't very strong
evidence. But maybe it is enough to induce a programmer who actually plays
in such games to create a more exhaustive test.

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Dynamic komi at high handicaps

[terry mcintyre]

Consider this thought experiment.

You sit down at a board and your opponent has a 9-stone handicap.

 
By any objective measure of the game, you should resign immediately.

All your win-rate calculations report this hopeless state of affairs. 

Winrate gives you no objective basis to prefer one move or another.

But, you think, what if I can make a small group? What if I try for a lesser 
goal, such as don't lose by more than 90 points?

Your opponent has a 9 stone handicap because he makes more mistakes than you 
do. 

As the game progresses, those mistakes add up. You set your goal higher - 
losing by only 50 points; losing by only 10 points. 

The changing goal permits you to discriminate in a field which would otherwise 
look like a dark, desolate, win-less landscape.

Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop





From: Don Dailey dailey@gmail.com
To: computer-go computer-go@computer-go.org
Sent: Wednesday, August 12, 2009 1:05:36 PM
Subject: Re: [computer-go] Dynamic komi at high handicaps

Ok,  I misunderstood his testing procedure.  What he is doing is far more 
scientific than what I thought he was doing.  

There has got to be something better than this.   What we need is a way to make 
the playouts more meaningful but not by artificially reducing our actual 
objective which is to win.

For the high handicap games,  shouldn't the goal be to maximize the score?   
Instead of adjusting komi why not just change the goal to win as much of the 
board as possible?This would be far more honest and reliable I would think 
and the program would not be forced to constantly waste effort on constantly 
changing goals.


- Don






On Wed, Aug 12, 2009 at 3:33 PM, Brian Sheppard sheppar...@aol.com wrote:

The small samples is probably the least of the problems with this.   Do you
actually believe that you can play games against it and not be subjective
in
your observations or how you play against it?

These are computer-vs-computer games. Ingo is manually transferring moves
between two computer opponents.

The result does support Ingo's belief that dynamic Komi will help programs
play high handicap games. Due to small sample size it isn't very strong
evidence. But maybe it is enough to induce a programmer who actually plays
in such games to create a more exhaustive test.

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/




  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Dynamic komi at high handicaps

[terry mcintyre]

Some algorithms are special-purpose by nature. What I sketched is an 
approximation of my understanding of how strong players defeat weaker players 
with large handicaps. When Myungwan Kim faced off against MFG a few days ago, 
with a 7 stone handicap, he had to come up with a strategy which would 
ultimately win a theoretically unwinnable game. 

When two pros face off, and one has a 7 stone handicap, the expectation is that 
the one with the handicap will not merely win, but win by 70 points. A pro with 
such a large handicap would be satisfied with nothing less. The Nihon Ki'in has 
published a book of pro-pro handicap games, where black exploits the full power 
of the handicap stones to give white a very thorough drubbing.

 
David Fotland might have some insights into how MFG viewed that game. Perhaps 
MFG thought it was so far ahead that it was indifferent about the various 
opening moves. Who cares if the win rate is 99.9998 or 99.7? But there are 
differences, which weaker players use to hang on to as much of their advantage 
as possible, and stronger players use to wear down that advantage. It becomes a 
war of attrition - whoever runs out of troops or ammo first loses the war. 

Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop




From: Don Dailey dailey@gmail.com
To: computer-go computer-go@computer-go.org
Sent: Wednesday, August 12, 2009 2:11:58 PM
Subject: Re: [computer-go] Dynamic komi at high handicaps

The problem with MCTS programs  is that they like to consolidate.   You set the 
komi and thereby give them a goal and they very quickly make moves which commit 
to that specific goal.   Commiting to less than you need to actually win will 
often involve sacrificing chances to win.Sometime it won't,  but you cannot 
have a scalable algorithm which is this arbitrary.

However, if the handicap is too high, the program thinks every line is a loss 
and it plays randomly.   That's why we even consider doing this.

Dynamically changing komi could be of some benefit in that situation if there 
is no alternative reasonable strategy,   but it does not address the real 
problem - which is what I call the committal consolidation problem.  You 
are giving the program an arbitrary short term goal which may,  or may not be 
compatible with the long term goal of winning the game. Whether it's 
compatible or not is based on your own credulity - not anything predictible or 
that you can scale.   And as the base program gets stronger this aspect of the 
program becomes more and more of a wart.   

If this can be made to work in the short term,  it should be considered a 
temporary hack which should be fixed as soon as possible.   

We have to think about this anyway sooner or later because if programs continue 
to develop and the predictive ability of the playouts and tree search gets 
several hundred ELO better,  these programs may start to see more and more 
positions as either dead won or dead lost.  I'm sure we will want some kind 
of robust mechanism for dealing with this which is better at estimating chances 
that the opponent will go wrong  as opposed to doing something that is a random 
benefit or hindrance. 

- Don


 





2009/8/12 terry mcintyre terrymcint...@yahoo.com

Ingo suggested something interesting - instead of changing the komi according 
to the move number, or some other fixed schedule, it varies according to the 
estimated winrate. 

It also, implicitly, depends on one's guess of the ability of the opponent. 

An interesting test would be to take an opponent known to be weaker, offer it 
a handicap, and tweak the dynamic komi per Ingo's suggestion. At what handicap 
does the ratio balance at 50:50? Can the number of handicap stones be 
increased with such an adaptive algorithm?

Even better, play against a stronger opponent; can one increase the win rate 
versus strong opponents?

The usual range of computer opponents is fairly narrow. None approach high-dan 
levels on 19x19 boards - yet.

 Terry McIntyre
 terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop




From: Brian Sheppard sheppar...@aol.com
To: computer-go@computer-go.org
Sent: Wednesday, August 12, 2009 12:33:13 PM
Subject: [computer-go] Dynamic komi at high handicaps


The small samples is probably the least of the problems with this.   Do you
actually believe that you can play games against it and not be subjective
in
your observations or how you play against it?

These are computer-vs-computer games. Ingo is manually transferring moves
between two computer opponents.

The result does support Ingo's belief that dynamic Komi will help programs
play high handicap games. Due to small sample size it isn't very strong
evidence. But maybe it is enough to induce a programmer who actually plays
in such games

Re: [computer-go] Dynamic komi at high handicaps

[terry mcintyre]

Most experiments are done on even games; this dynamic algorithm applies 
particularly to handicap games.In that context, it is not an ungainly kludge, 
but actually reflects the assessment of evenly matched pro players - they look 
at the board, and see a victory of n times 10 handicap stones ( or something 
roughly comparable ) for black. 

 
This matters because today's programs are not even close to playing at the pro 
level; to win respect, they'll have to master handicap games - and to do that, 
they'll need to do two things. First, they'll need to model the expectation 
that black with a handicap _should_ win big. Second, they'll need to behave 
gracefully as that initial advantage is whittled down. 

Existing programs don't do either of those two things well. They're tuned 
toward even-game strategy.

Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Dynamic komi at high handicaps

[terry mcintyre]

In practical terms, the problem to solve is the reverse: how do we encourage 
weak programs to hang on to as much of their advantage as possible, against 
stronger players? 

In 2020, we can worry about how to beat pro players who take large handicaps 
against computer programs.

Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop





From: Don Dailey dailey@gmail.com
To: computer-go computer-go@computer-go.org
Sent: Wednesday, August 12, 2009 2:51:09 PM
Subject: Re: [computer-go] Dynamic komi at high handicaps




2009/8/12 terry mcintyre terrymcint...@yahoo.com

Most experiments are done on even games; this dynamic algorithm applies 
particularly to handicap games.In that context, it is not an ungainly kludge, 
but actually reflects the assessment of evenly matched pro players - they look 
at the board, and see a victory of n times 10 handicap stones ( or something 
roughly comparable ) for black. 

 
This matters because today's programs are not even close to playing at the pro 
level; to win respect, they'll have to master handicap games - and to do that, 
they'll need to do two things. First, they'll need to model the expectation 
that black with a handicap _should_ win big. Second, they'll need to behave 
gracefully as that initial advantage is whittled down. 

I disagree.   I think strong players have a sense of what kind of mistakes to 
expect, and try to provoke those mistakes.   Dynamic komi does not model that.  
  

It also does the opposite of making the program play provocatively, which I 
believe is necessary to beat a weaker player with a large handicap against you. 
   Instead of making it fight,  it encourages the program to be content with 
less.   How does this model strong handicap players?  

- Don



 


Existing programs don't do either of those two things well. They're tuned 
toward
 even-game strategy.


Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop





___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/




  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Dynamic komi at high handicaps

[terry mcintyre]

As for how to beat weaker players ... the strong players whom I have observed 
make strong, stable positions; they wait for the weaker player to make 
mistakes. The stronger player will leave things unresolved for longer, knowing 
that there will be time to extend in one direction or another later in the 
game. 

They'll include some of the more interesting, obscure joseki, which the weaker 
player will not grok appropriately.

I have seen players who make unsound trick plays, but these are the kyu 
players; dan-level players know that trick plays can become costly mistakes. 
They'll use them for teaching purposes, not to win - but that's a different 
kind of game entirely.


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Congratulations to Aya!

[terry mcintyre]

Nick,

Many thanks for organizing this tournament!

Did intend to reverse simplebot and :weakbot50k in one of the duplicate 
simplebot descriptions?

 Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop





From: Nick Wedd n...@maproom.co.uk
To: computer-go computer-go@computer-go.org
Sent: Monday, August 10, 2009 8:21:59 AM
Subject: [computer-go] Congratulations to Aya!

Congratulations to Aya, winner of yesterday's KGS bot tournament.

My report is now at http://www.weddslist.com/kgs/past/50/index.html

As always, I will welcome comments and corrections.  But I am about to leave 
for a short holiday, so I won't respond to them for a few days.

Nick
-- Nick Weddn...@maproom.co.uk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] The AGA e-journal reports Man vs Machine Rematch

[terry mcintyre]

KIM PREVAILS AGAIN IN MAN VS MACHINE REMATCH: The Man vs Machine rematch Friday 
afternoon was anti-climactic, with Myeong-Wan Kim 8P (l) handily defeating Many
Faces of Go, playing with a 7-stone handicap and running a 32-core
processor. MoGo defeated Kim last year on 9 stones with an 800-core
processor. Kim beat Mogo – playing with 7 stones on a smaller processor
-- last fall at the Cotsen Open, narrowly defeating it at the very end.
“Many Faces was very different,” Kim told the audience after the game.
“It behaved more like a human, while MoGo was pure computer and very
unpredictable. It was easier to play Many Faces -- though it may be the
stronger program -- because I could predict what it was going to do.
Many Faces made better shape, but MoGo had better reading. I’d really
like to see both programs play each other and see what happens.” 
 Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] RAVE problems

[terry mcintyre]

Perhaps the context attached to RAVE needs to be more subtle than a static 
3x3 pattern - tactical and efficiency considerations may apply - a move may be 
good when it defends or kills a group, but bad if it has no effect upon the 
status - it may be wasted in such cases.


 Terry McIntyre terrymcint...@yahoo.com


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: Myungwan Kim 8P versus Many Faces of Go

[terry mcintyre]

Friday the 7th.

You may check ManyFaces1 on KGS -- this is the program which will be playing - 
it is using 8 cores now - may be using more cores by Friday.

 Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop





From: Ingo Althöfer 3-hirn-ver...@gmx.de
To: computer-go@computer-go.org
Sent: Thursday, August 6, 2009 12:48:53 AM
Subject: [computer-go] Re: Myungwan Kim 8P versus Many Faces of Go

Terry McI announced:
 On Friday, August 8th, at 3 PM  Eastern Daylight Time, 
 Myungwan Kim 8P will play against Many Faces of Go.

One question, do you mean
Friday, August 7th, 2009
or
Saturday, August 8th, 2009

or another year ;-)

Thanks for informing us.
Cheers, Ingo.

-- 
Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Myungwan Kim 8P versus Many Faces of Go

[terry mcintyre]

On Friday, August 8th, at 3 PM  Eastern Daylight Time, Myungwan Kim 8P will 
play against Many Faces of Go.

Exact details as to the handicap and the size of the cluster are not yet 
established.

This game will be played on KGS. It will played before an audience at the US Go 
Congress in Fairfax, Virginia.

 Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] CiteULike

[terry mcintyre]

I can't speak to that question, but the group was founded by Urban Hafner, and 
is still owned by him.

The last post I have seen by Urban Hafner was July 15, so he's probably still 
using that email account. 

Urban, are you there?

Thanks!

 Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop





From: Peter Drake dr...@lclark.edu
To: Computer Go computer-go@computer-go.org
Sent: Friday, July 24, 2009 10:31:43 AM
Subject: [computer-go] CiteULike

There is a CiteULike group dedicated to computer Go:

http://www.citeulike.org/group/5884/library

No new articles have been posted since May.

I tried to join a month ago to post an article, but there has been no response:

http://www.citeulike.org/groupfunc/5884/home

Is this group still active?

Thanks,

Peter Drake
http://www.lclark.edu/~drake/



___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] demo with pro at Go Congress in Fairfax

[terry mcintyre]

I'm trying to set up a demo game between Myungwan Kim and Mogo at the Go 
Congress in Fairfax, VA

Who should I speak with on the Mogo team? Will you be available? The Congress 
is from Aug 1-8. What times look good for you?

 
Thanks!

Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] demo with pro at Go Congress in Fairfax

[terry mcintyre]

I'd be happy to receive multiple offers; speak up!

 Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop





From: Peter Drake dr...@lclark.edu
To: computer-go computer-go@computer-go.org
Sent: Friday, July 24, 2009 3:37:16 PM
Subject: Re: [computer-go] demo with pro at Go Congress in Fairfax

Is MoGo still the best? Aren't Zen and ManyFaces doing better these days?

(Perhaps the real question is who has access to a supercomputer...)


On Jul 24, 2009, at 3:29 PM, terry mcintyre wrote:

I'm trying to set up a demo game between Myungwan Kim and Mogo at the Go 
Congress in Fairfax, VA

Who should I speak with on the Mogo team? Will you be available? The Congress 
is from Aug 1-8. What times look good for you?

 
Thanks!

Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop


___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Peter Drake
http://www.lclark.edu/~drake/


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Dead stones at end of game

[terry mcintyre]

On KGS, either player may mark stones as dead. If you disagree, you toggle the 
state of the stones. The game ends when both players click done -- you should 
do this only when you are entirely satisfied with the score. 

I don't know how the human interface maps to the API seen by the program.

 Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop





From: Jason House jason.james.ho...@gmail.com
To: computer-go computer-go@computer-go.org
Sent: Thursday, July 16, 2009 3:27:28 PM
Subject: Re: [computer-go] Dead stones at end of game


IIRC, the user can do whatever they want in a free game. Only rated games 
require the bot to agree with the scoring

Sent from my iPhone

On Jul 16, 2009, at 6:18 PM, Peter Drake dr...@lclark.edu wrote:


I was looking at this game that Orego played against a human on KGS recently:


Orego-Zanarkand.sgf


I note that Orego's dead stones are marked as dead, but Zanarkand's are not. 
Does KgsGtp defer to the human when there are disputes about dead stones? Is 
that the most likely explanation?


(What if there is a dispute between programs?)


Orego loses even if all of the dead stones are removed, but I'm a bit dismayed 
that Orego passed. (Zanarkand passed first.) I believe Orego reasoned, If I 
pass, the game ends, and if all stones on the board are alive, I win! I'll 
have to look into this...


Peter Drake
http://www.lclark.edu/~drake/


 

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: Dynamic komi in commercial programs

[terry mcintyre]

Maybe we should go back to the question which dynamic komi is an attempt to 
solve: how to obtain better discrimination when every move seems to be 
clustered near I am so freaking dead or I am so far ahead, as the case may 
be.


 Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop




From: Stefan Kaitschick stefan.kaitsch...@hamburg.de
To: computer-go computer-go@computer-go.org
Sent: Tuesday, July 14, 2009 3:17:38 PM
Subject: Re: [computer-go] Re: Dynamic komi in commercial programs

Dynamic komi in a sense means that the bot is deluding itself on purpose.
Obviously this is dangerous medicine, a kind of magic mushroom.
So what could be worse than a deluded bot?
I say, letting a monkey play could be worse.
And monkeys' play is what you get from an mc bot when all possible moves come 
back with indistinguishably
wonderful or terrible win rates.
Adding a wishful (or pessimistic) komi will distort reality, but will help 
create bigger win rate differences between moves.
It should be possible to assign costs to both dynamic komi and to 
insufficiently spreading win rates between moves.
My hypothesis is, that with unstable groups on the board, the win-rate spread 
will tend to be larger then with stable groups.
So with proper balancing, the bot should refuse to take dynamic komi when he 
sees a chance to win outright.

Stefan


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: Dynamic komi in commercial programs

[terry mcintyre]

Is it possible to design metrics for complexity of positions? An opponent 
model could make use of that information; there are positions which some 
players will totally fail to grok.

Double-digit kyu players are weak on life-and-death, ko, and seki. Some 
otherwise strong programs will fail to read seki properly. As players move up 
in rank, they read life-and-death at an earlier point. Human players, with 
practice, discover the weaknesses of their particular opponents.

Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop





From: Magnus Persson magnus.pers...@phmp.se

I am open to opponent modeling such as make the playouts of black in handicap 
games weaker. But in this case I think real gain if any would come from making 
the statistics more sensitive to the qualitative difference in available moves, 
rather than actually modeling the opponent, by bringing the win rates closer to 
50%. Although I think it would be really hard to degrade the black moves in the 
playouts in a realistic way.


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: Dynamic komi in commercial programs

[terry mcintyre]

That's an interesting idea - factoring in knowledge about the variability of 
a position. Certain parts of the board are going to be stable with alternating 
play - you attack, I defend, the position remains stable. Other parts of the 
board are less well-defined. On the 9x9 board, conflicts easily spill over; 
everything is inter-connected until the end-game. On the 19x19 board, it's 
possible to establish stable groups, and the action usually happens on the 
borders. Factor in seki, ko fights, etc. Simply varying  komi as some 
pre-ordained function of move number is unlikely to have enough granularity to 
cope with the structure of a particular game.

 Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop





From: Don Dailey dailey@gmail.com
To: computer-go computer-go@computer-go.org
Sent: Sunday, July 12, 2009 3:40:10 PM
Subject: Re: [computer-go] Re: Dynamic komi in commercial programs




On Sun, Jul 12, 2009 at 1:22 PM, Christian Nentwich 
christian.nentw...@gmail.com wrote:

Don, others,

are there publications about this? If people have tried it out, are
there any threads on this list that somebody remembers where results
are posted? I have not been able to find  any. It would be interesting
to see.

I think I just mentioned that there is probably not much on this except in the 
archive.And even then it's probably not very well documented.

I did try this myself but I don't have any data to show what I did.What I 
remember is that it's incredibly tricky - how do you actually know when and how 
much to adjust? If the score starts getting really low or really high, do 
you restart the search with a new komi?If you restart then you have wasted 
effort.  

I tried 2 different thing.  One of them involved using the total points won in 
some kind of hybrid approach and the other involved changing the komi during 
the game.   

Using JUST the total points won is a drastic weakening of the program and it's 
surprising how much.   I tried factoring in a percentage of total points won 
and other things.After some time I gave up - it seemed like I was taking 
something that worked well and trying to make it better by factoring in 
something that sucked. It was like trying to make it play better by putting 
something in on purpose that I knew makes it play worse.   

The dynamic komi adjustment, from my recollection was more promising, but still 
played worse.   The only way to make this work is if you know in advance what 
kind of position you really have.If you KNOW that you can pick off a small 
group without risk, then it probably would work just fine.But just 
increasing komi for no reason except that you are winning is not good enough.   
For instance if you KNOW there is a seki issue, then you should probably do it. 
   But just doing it because there MIGHT be a seki issue every 50 games that 
actually matters is not good enough.

You could call this a chicken and egg problem.You can of course easily 
construct positions that will illustrate how wonderful the idea is, and it will 
probably work great in those positions.Seki positions are always given as 
to why this will help - but not every game has a game critical seki.   But I'm 
pretty convinced you cannot generalize the idea.   You would have to do some 
kind of pre-analsysis to figure out what needs to be done,  and by then you may 
already know what to do anyway and you have a more convential program. 

- Don





Christian



2009/7/12 Don Dailey dailey@gmail.com:



 On Sun, Jul 12, 2009 at 8:59 AM, Benjamin Teuber benjamin.teu...@web.de
 wrote:

  You just hit the nail on the head.   Dynamic komi does not encourage a
  program to overplay the position.   Since you are starting from a losing
  position you HAVE to overplay a bit.   You have to attack when it is
  futile.

 That depends on the komi - if you're behind by fourty points and set
 the virtual komi to 30, you play as if you'd be 10 behind, which would
 be agressive, but not kamikaze.

 This is exactly what people do, so I don't see your point.

 It's not up to me to prove anything.   It's up to you.

 Several of us have tried variations of this idea of dynamic komi adjustment,
 which seems like a very good premise.  This SHOULD help the play.But the
 fact of the matter is that none of us (so far) has made it work.   If the
 observations do not fit the premise, at some point we should actually
 scrutinize the premise - even if the premise seems logical to us.

 I think the ones who still cling to this idea have not actually tried
 implementing it.Have you tried?If you have, why are still talking
 about it and not showing us something?


 - Don






 Benjamin
 ___
 computer-go mailing list
 computer-go@computer-go.org
 http://www.computer-go.org/mailman/listinfo/computer

Re: [computer-go] Dynamic komi in commercial programs

[terry mcintyre]

The go-playing literature offers a bit of advice: when ahead, make moves which 
simplify the game and preserve your advantage. When behind, take some risks to 
grab more than you are entitled to - but not too many. Computer programs seem 
bizarre in this regard, they tend to play quite unsatisfactory moves when 
behind. It would be more attractive to see the computer preserve its advantage, 
the better to spring when one's opponent lapses.


A complex seki was recently posted. Magnus explained that his program does not 
understand the seki per se, but finds the correct move through several 
intricately-meshed rules which prune bad moves. He's not entirely sure of the 
correctness of those rules - that is, whether they apply to all cases, or 
merely most cases. At the single-digit-kyu level, inducing sekis is not 
unusual; it is basic for dan-level players.

Some high-dan players prefer to give a large negative komi instead of handicap 
stones; the game mechanics are closer to those of an even game. The stronger 
player gains incrementally with every suboptimal move by the weaker; 
eventually, the advantage of the negative komi dissipates.

When can we train our programs, instructing them don't do that, it will only 
hurt you?



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Scoring - step function or sigmoid function?

[terry mcintyre]

To properly test any method of playing with a handicap, today's programs will 
need to play against much stronger opponents. Self-play, or play against other 
roughly-equal programs, won't test the ability to eke out a win against a 
professional go player.

Terry McIntyre terrymcint...@yahoo.com



“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop




  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Prediction

[terry mcintyre]

--- On Wed, 7/8/09, Michael Williams michaelwilliam...@gmail.com wrote:

From: Michael Williams michaelwilliam...@gmail.com

Prediction:

First, developers and algorithm gurus will expend huge amounts of effort to 
parallelize code to take advantage of multi-core chips.

Then, hardware engineers and physics gurus will give us light-based CPUs and 
orders of magnitude improvement in single-core performance.

Quite all right! light-based CPUs will come in multi-core versions too!



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Really basic question

[terry mcintyre]

megasnippage of Don's post:

 Adding an additional order of magnitude more time to the search [ in Rybka]  
 is not
going to change the basic misconception if the evaluation just doesn't
understand the position. [ Don suggests that this applies even more so to Go ]

Amen! We've covered variants of this theme a few times. 

I believe that when the playout component knows as much about life-and-death, 
corner plays, nakade, running fights, semeai, and seki as a dan-level player, 
the power of the tree search will leverage that knowledge far better than at 
present.

 Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Experimentation

[terry mcintyre]

Digesting Don's remarks, it seems that a reasonable method would start with 
equal numbers of simulations. It could then proceed to try various 
optimizations, and compare algorithms which use equal time. 

It makes perfect sense for the ultimate goal to be better performance using 
the same time or less, but it might be easier to progress stepwise - first 
tweak the top-level design, then tweak the performance - in order to separate 
out the different inputs to the experiment.

Terry McIntyre terrymcint...@yahoo.com



“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop




  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Hash tables

[terry mcintyre]

Considering that memory keeps getting cheaper, would it make sense to 
dynamically choose how much space to use?

 
Nowadays most new computer purchasers start with 2 GB, and go up from there. 

Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop





From: David Fotland fotl...@smart-games.com
To: computer-go computer-go@computer-go.org
Sent: Sunday, July 5, 2009 9:05:45 PM
Subject: RE: [computer-go] Hash tables

The hash table contains a linked list of nodes with the same hash index.  

Your description is pretty close, but I don't remember the exact details.
Yes, I keep around some nodes for while, but eventually old nodes go into
the past and can be recovered.

I actually have fewer total nodes than you do.  The commercial version
allocates 30K nodes per CPU core.  The version in the world championship had
much more, but the commercial version can't be that greedy for memory.

David

 
  I give up when there are no nodes that area available to be
  overwritten.
 
 I'm still a little confused.
 
 First, does the hash table contains pointers into a node pool, or do
 you use the node pool as the hash table?
 
 Second, how and when do you determine which nodes (if any) are
 available for overwriting, without doing some sort of traversal?
 
 Is the following a correct summary of what you do when it's time to
 create a new node?
 
 Go to the one node that would be used for this Zobrist hash. If the
 same hash is stored there, use the existing node. If not, either
 overwrite this node (if this node is available for overwriting) or not
 create a new node (otherwise).
 
 Also, what exactly is the criterion for overwriting? You said nodes
 that have few visits or are old. Is this just (visits 
 visitThreshold) || (depthFromBeginningOfGame  currentGameTurn)?
 Doesn't depthFromBeginningOfGame cause you to keep around nodes that
 are outside the still-relevant branch of the tree (i.e., the branch
 descending from the current root), almost all of which are irrelevant?
 
  If the search is long enough, there are no nodes that can be
  recovered, and the
  UCT tree stops growing.  I keep searching when there are no reusable
  nodes.
 
 
 ...because this improves the quality of information in the nodes you
 were able to create. That makes sense.
 
 Thanks,
 
 Peter Drake
 http://www.lclark.edu/~drake/
 
 ___
 computer-go mailing list
 computer-go@computer-go.org
 http://www.computer-go.org/mailman/listinfo/computer-go/

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Fuego or Fuego?

[terry mcintyre]

From merriam webster entry for terra del fuego, it can be foo-ay-go or 
fway-go

It's a Spanish word -- have to ask some Spanish speakers their opinions.

http://forvo.com/word/fuego/ -- to my ear, it sounds like foo eh go -- three 
distinct syllables.

Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop





From: Michael Williams michaelwilliam...@gmail.com
To: computer-go computer-go@computer-go.org
Sent: Friday, June 19, 2009 10:58:14 AM
Subject: [computer-go] Fuego or Fuego?

Is it pronounced few-go or fway-go?
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] MCTS, 19x19, hitting a wall?

[terry mcintyre]

From: Don Dailey dailey@gmail.com

 My basic observation is that over the several year period I have been in this 
 forum,  I have detected a huge amount of resistance to the idea that hardware 
 could have anything to do with computer go strength, despite the fact that it 
 keeps proving to be so.   The resistance is strong enough that we have to 
 explain it way when it happens, by saying things like we have hit a wall and 
 it won't happen any more thank goodness.

You overrstate the resistance - it's not that anybody is saying hardware is 
irrelevant. In fact, did we not have a recent discussion over the merits of two 
different CPU variations? We've seen a fair number of multi-processor entrants 
at competitions, besides.

The questions ishow much does hardware matter? So far, we have one data point 
to work with: David Fotland's excellent Many Faces of Go is about one stone 
stronger when it uses 32 cores instead of 2. That's nice to have, but if we 
extrapolate, a factor of 16 is 3 doublings or about 4.5 years, in terms of 
Moore's Law. It will only take 9*4.5,  roughly 40 years, to reach pro-level 
play. 

We don't have data from Mogo yet, but I wonder if they are seeing 2-3 stones 
improvement for their 3200-node version?

The less patient among us may wish to seek algorithmic improvements to bridge 
the gap a bit sooner. 

Got to be some reason for bright programmers and mathematicians to work on the 
problen, after all; otherwise we could just wait 40 years for Intel and AMD to 
deliver 32,768 cores on a single chip - or will it be a silicon wafer?

In other fields, algorithmic improvements have led multiple orders of magnitude 
improvement in running time. Humans manage to complete 30-minute games on a 
19x19 board, so we do have evidence that the game can be played well at such a 
speedy pace.


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] MCTS, 19x19, hitting a wall?

[terry mcintyre]

Regarding Moore's Law, I'd love to hear the Mogo team's perspective on this; 
they have probably had more opportunity to test their algorithms extensively on 
big-n-count computers than any of us.

If I recall correctly, the Huygens supercomputer uses 800 to 3200 cores -- one 
to four hundred times the equivalent of an 8 core machine, which might be 
considered a reasonable investment for a well-heeled enthusiast.

How much stronger is the 800 or 3200-core version of Mogo, compared to the 4 or 
8 core version, for the same time limits, on 19x19 Go?


David Fotland has done quite a bit with a 32-core machine, I believe. How much 
stronger is MFG on 32 cores versus 4, for the same time limits, on 19x19 Go?
 
Hopefully, how much stronger would be tested with something other than 
self-play against a weaker program - play on KGS, or CGOS, or something more 
diverse than a weaker clone of oneself.

Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] US Go Congress

[terry mcintyre]

I can volunteer to organize the computer versus pro demonstration. 

Myung-Wan Kim lives in Los Angeles and I can approach him; he played against 
Mogo last year.

Will Mogo be available?

Mogo team, do you feel that Mogo has improved since the previous demonstration?

Which is the strongest computer go program nowadays?

 Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop




From: David Doshay ddos...@mac.com
To: computer-go computer-go@computer-go.org
Sent: Tuesday, June 9, 2009 10:56:30 AM
Subject: Re: [computer-go] US Go Congress

Because of my health problems I will not be able to attend this year either, so 
neither of the two people who ran last year's event in Portland will be able to 
do it this year.

Any other volunteers? It would be nice if this became a regular event again.

Cheers,
David



On 9, Jun 2009, at 9:27 AM, Peter Drake wrote:

 Due to other commitments, I will NOT be attending the US Go Congress in 
 Fairfax, Virginia, August 1-9. As a result, if there is to be any computer Go 
 event there (e.g., computer-computer tournament, computer-professional 
 match), someone else will have to organize it.
 
 Peter Drake
 http://www.lclark.edu/~drake/
 
 
 
 ___
 computer-go mailing list
 computer-go@computer-go.org
 http://www.computer-go.org/mailman/listinfo/computer-go/

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] bots and handicaps (Re: New CGOS)

[terry mcintyre]

Pro ranks are assumed to be about 1/3 of a stone; the one stone per rank 
formula applies to amateur ranks.

 
I have watched a pro 8p regularly give three stones to a 6 dan amateur. A 
weaker pro might give the same player 2 stones.

Some ( including myself in the past ) have argued that they can easily beat a 
person who is nine ranks higher with a nine stone handicap. I have done this 
often enough that I believed it. However, after losing a fair number of such 
9-stone games, I conclude that many people slack off, assuming that their 
opponent is really inept; if the weaker player can keep most of his groups 
alive, and pressure white, he will win. When white aggressively exploits weak 
groups, the weaker player's positions collapse. A dan-level player has an 
understanding of life and death which seems almost magical to a weaker player. 
When that superior knowledge is exploited, the weaker player crumbles.

Last week, I played a series of 9-stone games. After losing three in a row, my 
opponent thanked me for giving him a serious challenge. I think many players do 
not rise to that challenge; they don't apply their full strength against 
kyu-level players.

Until computer programs rise to the level of even play against pros, 
human-computer matches will be handicap games. It makes sense to develop the 
ability to play handicap games well. It would be sad if a program with a seven 
stone handicap frittered away its advantage instead of hoarding it jealously.

Terry McIntyre terrymcint...@yahoo.com


Any system of entrusting the government to judge and correct its own abuses is 
the same as appointing the accused criminal as his own judge and jury: don't 
expect many convictions.

-- Allen Thornton, Laws of the Jungle


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] bots and handicaps (Re: New CGOS)

[terry mcintyre]

I was referring to matches against pro players. It's going to be a while before 
a computer can win even games against pros, therefore we must assume that any 
such matches will involve the program taking a handicap.

My personal preference is the strongest possible opponent. When reviewing games 
that I have won against computer programs, I find that tweaking just one 
computer move would often destroy my position; hence, I was getting false 
feedback, believing my position to be superior when in fact it was terribly 
weak.

 
Play against devastatingly strong opponents (from my point of view) has 
motivated me to discover (and hopefully repair) weaknesses in my reading 
skills. Playing against opponents of my level only encourages me to be a little 
trickier - to push problems beyond the horizon of my opponent's skills (and 
often my own).

Terry McIntyre terrymcint...@yahoo.com


Any system of entrusting the government to judge and correct its own abuses is 
the same as appointing the accused criminal as his own judge and jury: don't 
expect many convictions.

-- Allen Thornton, Laws of the Jungle




From: David Fotland fotl...@smart-games.com
To: computer-go computer-go@computer-go.org
Sent: Sunday, June 7, 2009 11:06:37 AM
Subject: RE: [computer-go] bots and handicaps (Re: New CGOS)

 
I can’t really agree with this statement.  My customers tell me
they would much rather play a challenging even game against an opponent of
their level, than a challenging handicap game against a much stronger or much
weaker opponent.  This is why version 12 of Many Faces has levels that are 
calibrated
to be about 3 stones apart, so there is always a level that does not require a
handicap, unless you are weaker than 20 kyu or stronger than 1 dan.
 

Until computer programs rise to the level of even play against pros,
human-computer matches will be handicap games. It makes sense to develop the
ability to play handicap games well. It would be sad if a program with a seven
stone handicap frittered away its advantage instead of hoarding it jealously.
Terry McIntyre
terrymcint...@yahoo.com


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] New CGOS

[terry mcintyre]

The purpose of a handicap games is to allow a 50% chance of either contestant 
winning.

If one program loses 100% of games against another, it would take a vast 
improvement to advance to 90% or 80%. If the same two programs have an 
appropriate handicap, and a base of 50% odds, it should be easier to see the 
beneficial impact of various changes.

 
Contrast my winrate against a motley assortment of opponents, which changes 
month-to-month, is 3% higher than yours with my program can give yours two 
stones, and still win 50%  of the games. Programs do not care, but their human 
designers might have an incentive to find a way to leapfrog over their 
opponents.
Terry McIntyre terrymcint...@yahoo.com


Any system of entrusting the government to judge and correct its own abuses is 
the same as appointing the accused criminal as his own judge and jury: don't 
expect many convictions.

-- Allen Thornton, Laws of the Jungle




From: Christoph Birk b...@ociw.edu
To: computer-go computer-go@computer-go.org
Sent: Friday, June 5, 2009 2:59:07 PM
Subject: Re: [computer-go] New CGOS

On Fri, 5 Jun 2009, Don Dailey wrote:
 Handicap games opens a can of worms.   The last time we discussed it,
 it was difficult to get any kind of reasonable agreement on how to do it.

Handicap games are for humans ... they get frustrated losing
over and over. Computers have no problems with that.
I agree with Don, adding a handicap server is an unnecessary complication.

Christoph

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: Implications of a CPU vs Memory trend on MCTS

[terry mcintyre]

I concur with Don; for the early moves, this is likely to be helpful. On a 
19x19 board, the first ten or fifteen moves of a pro game often follow fairly 
well-known patterns, but it's not enough to simply memorize the patterns; there 
is deep knowledge which explains why one 3,4 point is better than the other, or 
why a particular joseki matches the overall position, and another is a failure. 
Building up a tree over time which knows something about the various choices 
might be helpful.
 
Terry McIntyre terrymcint...@yahoo.com


On general principles, when we are looking for a solution of a social problem, 
we must expect to reach conclusions quite opposed to the usual opinions on the 
subject; otherwise it would be no problem. We must expect to have to attack, 
not what is commonly regarded as objectionable, but what is commonly regarded 
as entirely proper and normal. 


– John Beverley Robinson, 1897


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Implications of a CPU vs Memory trend on MCTS

[terry mcintyre]

Memory-aware algorithms take advantage of the varying access characteristics. 
Long, long ago, computer memory was actually a rotating drum; each instruction 
chained to the next location; it was worth a lot of effort to place the 
instructions in such a manner that they'd be where you need them when they were 
needed.

Not every bit of information needs to be available Right Now; if we map access 
needs to the access capabilities, an SSD can be a great way to extend RAM 
cheaply. This is all the more true when newer flavors of SSD become available 
in the next few years.

 Terry McIntyre terrymcint...@yahoo.com


On general principles, when we are looking for a solution of a social problem, 
we must expect to reach conclusions quite opposed to the usual opinions on the 
subject; otherwise it would be no problem. We must expect to have to attack, 
not what is commonly regarded as objectionable, but what is commonly regarded 
as entirely proper and normal. 


– John Beverley Robinson, 1897





From: Michael Williams michaelwilliam...@gmail.com
To: computer-go computer-go@computer-go.org
Sent: Tuesday, May 12, 2009 9:48:19 AM
Subject: Re: [computer-go] Implications of a CPU vs Memory trend on MCTS

It depends on how you use it and how much you pay for it.  If you get a 
high-end Intel SSD, you can treat it however you like.  But I can't afford 
that.  I got 
a cheap SSD and so I had shape my algorithm around which kind of disk 
operations it likes and which ones it doesn't.


steve uurtamo wrote:
 is the ssd fast enough to be practical?
 
 s.
 
 On Tue, May 12, 2009 at 12:41 PM, Michael Williams
 michaelwilliam...@gmail.com wrote:
 Don Dailey wrote:
 On Tue, May 12, 2009 at 12:16 PM, Michael Williams
 michaelwilliam...@gmail.com mailto:michaelwilliam...@gmail.com wrote:

I have a trick  ;)

I am currently creating MCTS trees of over a billion nodes on my 4GB
machine.


 Ok,  I'll bite.What is your solution?
 I use an SSD.  There are many details, of course.  But it's still in the
 works and I'm still making lots of changes and adjustments.  I seem to be
 able to solve (there are lots of definitions) 6x6 Go in that when I use a
 komi of 3.5, it is unable to find a winning line for white and when I use
 4.5, it is unable to find a winning line for black.

 ___
 computer-go mailing list
 computer-go@computer-go.org
 http://www.computer-go.org/mailman/listinfo/computer-go/

 ___
 computer-go mailing list
 computer-go@computer-go.org
 http://www.computer-go.org/mailman/listinfo/computer-go/
 

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Implications of a CPU vs Memory trend on MCTS

[terry mcintyre]

Are we approaching a point where it would be practical to precompute the 
opening tree to some depth, cache the results on SSD, and incrementally improve 
that knowledge based upon subsequent games?

 Terry McIntyre terrymcint...@yahoo.com


On general principles, when we are looking for a solution of a social problem, 
we must expect to reach conclusions quite opposed to the usual opinions on the 
subject; otherwise it would be no problem. We must expect to have to attack, 
not what is commonly regarded as objectionable, but what is commonly regarded 
as entirely proper and normal. 


– John Beverley Robinson, 1897





From: Michael Williams michaelwilliam...@gmail.com
To: computer-go computer-go@computer-go.org
Sent: Tuesday, May 12, 2009 10:18:28 AM
Subject: Re: [computer-go] Implications of a CPU vs Memory trend on MCTS

In my system, I can retrieve the children of any node at a rate of about 100k 
nodes/sec.

And I can save nodes at a rate of over 1M nodes/sec (this is much faster 
because in my implementation, the operation is sequential on disk).

Those numbers are from 6x6 testing.


Don Dailey wrote:
 This is probably a good solution.   I don't believe the memory has to be very 
 fast at all because even with light playouts you are doing a LOT of 
 computation between memory accesses.  
 All of this must be tested of course. In fact I was considering if disk 
 memory could not be utilized as a kind of cache.   The secret would be to 
 store complete trees in disk memory, trees that are not likely to be utilized 
 but can be utilized in a pinch.   The tree store and retrieved must outweigh 
 by a large factor the amount of time spent creating the tree in the first 
 place in order for this to pay off. 
 My guess is that this is impractical, but it's fun to think about how it 
 might be done.   I'm not sure how to do it without having a caching nightmare.
 
 
 - Don
 
 
 
 On Tue, May 12, 2009 at 12:41 PM, Michael Williams 
 michaelwilliam...@gmail.com mailto:michaelwilliam...@gmail.com wrote:
 
 Don Dailey wrote:
 
 On Tue, May 12, 2009 at 12:16 PM, Michael Williams
 michaelwilliam...@gmail.com
 mailto:michaelwilliam...@gmail.com
 mailto:michaelwilliam...@gmail.com
 mailto:michaelwilliam...@gmail.com wrote:
 
I have a trick  ;)
 
I am currently creating MCTS trees of over a billion nodes on
 my 4GB
machine.
 
 
 Ok,  I'll bite.What is your solution?
 
 
 I use an SSD.  There are many details, of course.  But it's still in
 the works and I'm still making lots of changes and adjustments.  I
 seem to be able to solve (there are lots of definitions) 6x6 Go in
 that when I use a komi of 3.5, it is unable to find a winning line
 for white and when I use 4.5, it is unable to find a winning line
 for black.
 
 
 ___
 computer-go mailing list
computer-go@computer-go.org mailto:computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
 
 
 
 
 
 ___
 computer-go mailing list
 computer-go@computer-go.org
 http://www.computer-go.org/mailman/listinfo/computer-go/

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Implications of a CPU vs Memory trend on MCTS

[terry mcintyre]

How long has it been pondering?

 Terry McIntyre terrymcint...@yahoo.com


On general principles, when we are looking for a solution of a social problem, 
we must expect to reach conclusions quite opposed to the usual opinions on the 
subject; otherwise it would be no problem. We must expect to have to attack, 
not what is commonly regarded as objectionable, but what is commonly regarded 
as entirely proper and normal. 


– John Beverley Robinson, 1897





From: Michael Williams michaelwilliam...@gmail.com
To: computer-go computer-go@computer-go.org
Sent: Tuesday, May 12, 2009 1:09:41 PM
Subject: Re: [computer-go] Implications of a CPU vs Memory trend on MCTS

That's basically what I'm doing.  Except that there is no depth limit and only 
the parts of the tree that you need get loaded back into memory.  It's not a 
playing engine yet so it can't build the tree as it plays games.  Currently it 
just ponders the empty board.


terry mcintyre wrote:
 Are we approaching a point where it would be practical to precompute the 
 opening tree to some depth, cache the results on SSD, and incrementally 
 improve that knowledge based upon subsequent games?
  Terry McIntyre terrymcint...@yahoo.com
 
 On general principles, when we are looking for a solution of a social 
 problem, we must expect to reach conclusions quite opposed to the usual 
 opinions on the subject; otherwise it would be no problem. We must expect to 
 have to attack, not what is commonly regarded as objectionable, but what is 
 commonly regarded as entirely proper and normal.
 
 
 – John Beverley Robinson, 1897
 
 
 
 *From:* Michael Williams michaelwilliam...@gmail.com
 *To:* computer-go computer-go@computer-go.org
 *Sent:* Tuesday, May 12, 2009 10:18:28 AM
 *Subject:* Re: [computer-go] Implications of a CPU vs Memory trend on MCTS
 
 In my system, I can retrieve the children of any node at a rate of about 100k 
 nodes/sec.
 
 And I can save nodes at a rate of over 1M nodes/sec (this is much faster 
 because in my implementation, the operation is sequential on disk).
 
 Those numbers are from 6x6 testing.
 
 
 Don Dailey wrote:
   This is probably a good solution.  I don't believe the memory has to be 
 very fast at all because even with light playouts you are doing a LOT of 
 computation between memory accesses.   All of this must be tested of course. 
In fact I was considering if disk memory could not be utilized as a kind 
 of cache.  The secret would be to store complete trees in disk memory, trees 
 that are not likely to be utilized but can be utilized in a pinch.  The tree 
 store and retrieved must outweigh by a large factor the amount of time spent 
 creating the tree in the first place in order for this to pay off.
   My guess is that this is impractical, but it's fun to think about how it 
 might be done.  I'm not sure how to do it without having a caching nightmare.
  
  
   - Don
  
  
  
   On Tue, May 12, 2009 at 12:41 PM, Michael Williams 
 michaelwilliam...@gmail.com mailto:michaelwilliam...@gmail.com 
 mailto:michaelwilliam...@gmail.com mailto:michaelwilliam...@gmail.com 
 wrote:
  
  Don Dailey wrote:
  
  On Tue, May 12, 2009 at 12:16 PM, Michael Williams
  michaelwilliam...@gmail.com mailto:michaelwilliam...@gmail.com
  mailto:michaelwilliam...@gmail.com 
 mailto:michaelwilliam...@gmail.com
  mailto:michaelwilliam...@gmail.com 
 mailto:michaelwilliam...@gmail.com
  mailto:michaelwilliam...@gmail.com 
 mailto:michaelwilliam...@gmail.com wrote:
  
  I have a trick  ;)
  
  I am currently creating MCTS trees of over a billion nodes on
  my 4GB
  machine.
  
  
  Ok,  I'll bite.What is your solution?
  
  
  I use an SSD.  There are many details, of course.  But it's still in
  the works and I'm still making lots of changes and adjustments.  I
  seem to be able to solve (there are lots of definitions) 6x6 Go in
  that when I use a komi of 3.5, it is unable to find a winning line
  for white and when I use 4.5, it is unable to find a winning line
  for black.
  
  
  ___
  computer-go mailing list
  computer-go@computer-go.org mailto:computer-go@computer-go.org 
 mailto:computer-go@computer-go.org mailto:computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
  
  
  
   
  
   ___
   computer-go mailing list
   computer-go@computer-go.org mailto:computer-go@computer-go.org
   http://www.computer-go.org/mailman/listinfo/computer-go/
 
 ___
 computer-go mailing list
 computer-go@computer-go.org mailto:computer-go@computer-go.org
 http://www.computer-go.org

Re: [computer-go] Re: Implications of a CPU vs Memory trend on MCTS

[terry mcintyre]

In the opening, among reasonably clueful players, the branching factor is much 
closer to 10 than to 361.

 Terry McIntyre terrymcint...@yahoo.com


On general principles, when we are looking for a solution of a social problem, 
we must expect to reach conclusions quite opposed to the usual opinions on the 
subject; otherwise it would be no problem. We must expect to have to attack, 
not what is commonly regarded as objectionable, but what is commonly regarded 
as entirely proper and normal. 


– John Beverley Robinson, 1897





From: Michael Williams michaelwilliam...@gmail.com
Subject: Re: [computer-go] Re:  Implications of a CPU vs Memory trend on MCTS

You have made the assumption that the move that your opponent selected was on 
average explored equally as much as all of the other moves.  That seems a bit 
pessimistic.  One would expect that the opponent selected a strong move and one 
would also expect that your tree explored that strong move more than it did 
other moves.  I'm not saying keeping the tree is a huge benefit.  I'm just 
saying that I don't think your 99% number is fair.



Dave Dyer wrote:
 At 02:13 PM 5/12/2009, Michael Williams wrote:
 Where does your 99% figure come from?
 
 1/361  1%
 
 by endgame there are still easily 100 empty spaces
 on the board.
 
 
 ___
 computer-go mailing list
 computer-go@computer-go.org
 http://www.computer-go.org/mailman/listinfo/computer-go/
 

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: Implications of a CPU vs Memory trend on MCTS

[terry mcintyre]

It's possible for the tree to become too narrow. On a 9x9 board, you might be 
able to say that there are only one or two playable moves, but on 19x19, I 
doubt that any pro would claim that the options are that narrow, even 
accounting for symmetry, It's common to hear that some pros play A, some B, 
some C or D in this situation. Moderately strong amateurs play one of these 
other options, which are mistakes because ... 


An opening book could benefit from knowing how to respond to the options 
considered by both pros and strong amateurs. As for weaker players like me, we 
tend to be somewhat more creative, you'll just have to work it out on the fly.

I think an efficient opening book would be organized on principles similar to 
huffman encoding: it would devote space to high-probability branches, and less 
to the weird stuff - but enough memory might be retained to eventually observe 
Gee, opponent X does this a lot, and I have discovered a good refutation Y.

Terry McIntyre terrymcint...@yahoo.com


On general principles, when we are looking for a solution of a social problem, 
we must expect to reach conclusions quite opposed to the usual opinions on the 
subject; otherwise it would be no problem. We must expect to have to attack, 
not what is commonly regarded as objectionable, but what is commonly regarded 
as entirely proper and normal. 
But as Don says, this needs to be integrated with the basic search algorithm to 
scale well.

I recently tried a few games against Leela, where the first 8 opening plays 
were predetermined ( a mini chinese opening ). This is not the usual style of 
Leela. I find that I can win either side of the same position. When Leela and I 
start with an empty board, I have a harder time of it; Leela's style is not 
mine.


– John Beverley Robinson, 1897




From: Don Dailey dailey@gmail.com
To: computer-go computer-go@computer-go.org
Sent: Tuesday, May 12, 2009 3:14:55 PM
Subject: Re: [computer-go] Re: Implications of a CPU vs Memory trend on MCTS



On Tue, May 12, 2009 at 6:05 PM, Don Dailey dailey@gmail.com wrote:

And for MCTS it is much lower than 10.



2009/5/12 terry mcintyre terrymcint...@yahoo.com

In the opening, among reasonably clueful players, the branching factor is much 
closer to 10 than to 361.

I assume Dave Dyer does not understand alpha beta pruning either, or he would 
not assume the branching factor is 361.But the pruning we are doing is far 
more severe than even alpha/beta pruning.(In a theoretical sense this is  
not true because a proper MCTS eventually would have to explore the tree in 
alpha/beta fashion to provide a proof.)In practical MC programs the 
effective BF is extremely low.   

- Don
 
 


 Terry McIntyre terrymcint...@yahoo.com


On general principles, when we are looking for a solution of a social problem, 
we must expect to reach conclusions quite opposed to the usual opinions on the 
subject; otherwise it would be no problem. We must expect to have to attack, 
not what is commonly regarded as objectionable, but what is commonly regarded 
as entirely proper and normal. 


– John Beverley Robinson, 1897





From: Michael Williams michaelwilliam...@gmail.com
Subject: Re: [computer-go] Re:  Implications of a CPU vs Memory trend on MCTS


You have made the assumption that the move that your opponent selected was on 
average explored equally as much as all of the other moves.  That seems a bit 
pessimistic.  One would expect that the opponent selected a strong move and one 
would also expect that your tree explored that strong move more than it did 
other moves.  I'm not saying keeping the tree is a huge benefit.  I'm just 
saying that I don't think your 99% number is fair.



Dave Dyer wrote:
 At 02:13 PM 5/12/2009, Michael Williams wrote:
 Where does your 99% figure come from?
 
 1/361  1%
 
 by endgame there are still easily 100 empty spaces
 on the board.
 
 
 ___
 computer-go mailing list
 computer-go@computer-go.org
 http://www.computer-go.org/mailman/listinfo/computer-go/
 

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/



___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] a ladder example

[terry mcintyre]

I promised an example of a monte carlo program mistakenly starting a ladder; 
here it is.

I played white; Leela had a 2 stone handicap and 45 minutes on the clock.

Leela's move 32 initiates a ladder. Unfortunately for Leela, I have a ladder 
breaker at D16. 

Leela's analysis was optimistic when it initiated the ladder, but a few moves 
later, it became aware of the looming shadow of a great doom.

There are a few large captures later in the game. The corner fight at the end 
had me biting my nails.

 Terry McIntyre terrymcint...@yahoo.com


Here you can see how slightly a people needs to be governed. - Carl Schurz, 
immigrant, 1848.
What happened since?



  

score_me.sgf
Description: Binary data
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] a ladder example

[terry mcintyre]

Is it practical to recognize the initiation of a ladder, and expand the nodes 
all the way to the end, to determine whether it works or not? More generally 
speaking, if a large group can be repeatedly put into atari, the outcome will 
usually swing the game one way or the other. One of the players pursuing a 
ladder has usually made a fatal error; Hugh Grant Important to know.

 Terry McIntyre terrymcint...@yahoo.com


Here you can see how slightly a people needs to be governed. - Carl Schurz, 
immigrant, 1848.
What happened since?





From: David Fotland fotl...@smart-games.com
To: computer-go computer-go@computer-go.org
Sent: Saturday, May 2, 2009 11:35:36 AM
Subject: RE: [computer-go] a ladder example


I think all uct/mc programs will have this problem unless they
add something extra to avoid it.  During playouts using random moves the
playouts will think that the ladder usually works.  Local 3x3 patterns aren’t
enough since they can’t tell the difference between ladders that work and
ladders that don’t work.  Some programs read ladders during playouts
so they know the local result and can play correctly.  Many Faces doesn’t
read ladders during playouts, since I think it’s too slow, but I found a
different solution to the problem.
 
Mogo and Crazystone must some solution to this problem, but I don’t
know what it is.
 
This should only show up for long ladders, since the UCT tree
part of the search will read a ladder correctly.  
 
David
 
From:computer-go-boun...@computer-go.org
[mailto:computer-go-boun...@computer-go.org] On Behalf Of terry mcintyre
Sent: Saturday, May 02, 2009 9:49 AM
To: computer go
Subject: [computer-go] a ladder example
 
I promised an
example of a monte carlo program mistakenly starting a ladder; here it is.
 
I played white;
Leela had a 2 stone handicap and 45 minutes on the clock.
 
Leela's move 32
initiates a ladder. Unfortunately for Leela, I have a ladder breaker at
D16. 
 
Leela's analysis
was optimistic when it initiated the ladder, but a few moves later, it became
aware of the looming shadow of a great doom.
 
There are a few
large captures later in the game. The corner fight at the end had me biting my
nails.
 
Terry McIntyre terrymcint...@yahoo.com
Here you
can see how slightly a people needs to be governed. - Carl Schurz,
immigrant, 1848.
What happened since?


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Monte-Carlo Simulation Balancing

[terry mcintyre]

A fair number of amateur moves are exactly what a pro would use; this is no 
great surprise, since the moves are actually copied from professional games. 
The weaker player can blindly emulate, but does not know why a pro plays A 
instead of B or C; does not know how to punish slack moves.

I've been taking some classes from an 8d pro. Sadly, I'm at the bottom of the 
class. The top players in these classes are 8d amateurs; the pro can give them 
3 stones and win. When going over their games, many of their moves are quite 
respectable, but the pro is able to find mistakes which can be exploited with 
devastating effect. You can't afford to be a little bit off against a pro, 
but weaker players find it hard to exploit slack moves.

 
When explaining his moves, the pro often uses very deep reading. We've all seen 
simple cases, where move A is advisable if a ladder works, otherwise B is 
recommended. The pro knows six moves in advance that he'll need to read that 
ladder, before the ladder is actually on the board. These are the simplest 
expositions I've seen; things get more complex from there. 
Terry McIntyre terrymcint...@yahoo.com


Government is an association of men who do violence to the rest of us.
- Leo Tolstoy





From: steve uurtamo uurt...@gmail.com
To: computer-go computer-go@computer-go.org
Sent: Tuesday, April 28, 2009 5:09:20 PM
Subject: Re: [computer-go] Monte-Carlo Simulation Balancing

also, i'm not sure that a lot of most amateurs' moves are very
good.  the spectrum of bad moves is wide, it's just that it takes
someone many stones stronger to severely punish small differences
between good and nearly-good moves.  among players of relatively
similar strength, these differences will go unnoticed and unpunished.

s.

2009/4/28 Don Dailey dailey@gmail.com:
 A simplistic model that helps explain this is golf.   On a single hole, even
 a casual golfer has a realistic chance of out-golfing Tiger Woods.  Tiger
 occasionally shoots a 1 over par on some hole and even weak amateurs
 occasionally par or even birdie a hole.It's not going to happen a lot,
 but it's not ridiculous either.   Years ago I taught a player how to golf,
 and on his third time out with me,  he hit a hole in one on a short par
 3. If Tiger Woods had been playing with us, he would have lost that hole
 to this beginner.

 But in a 9 hole match,  the odds go down enormously - for all practical
 purposes there is no chance.

 I kind of think of GO like that, even though it's a pretty simplistic
 model.   Each move is like a hole of golf,  it can be a good shot or a bad
 one. With GO, however, probably a LOT of your moves are just as good as
 the moves of a good player.   But it's the ones that fall short, that kill
 you.

 Go on a big board is like 18 holes of golf  compared to just 1 or 2 holes of
 golf.   The better player is far more likely to win the 18 hole match than
 the 1 hole match.

 - Don





 On Tue, Apr 28, 2009 at 1:53 PM, Ivan Dubois dubois_i...@yahoo.fr wrote:

 I noticed that, in general, changes in the playout policy have a much
 bigger impact on larger boards than on smaller boards.

 Rémi

 I think rating differences are emplified on larger boards. This is easy to
 see if you think about it this way :

 Somehow a 19x19 board is like 4 9x9 boards. Let us define a new game that
 I would call 4-Go where instead of playing one game, you play simultenously
 4 games and determine the winner by calculating the sum of the scores of the
 four games. Certainly rating differences would be bigger with 4-go than with
 go (given the same two players). This explains why rating differences are
 bigger on 19x19 than 9x9.

 Ivan

 ___
 computer-go mailing list
 computer-go@computer-go.org
 http://www.computer-go.org/mailman/listinfo/computer-go/


 ___
 computer-go mailing list
 computer-go@computer-go.org
 http://www.computer-go.org/mailman/listinfo/computer-go/

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Roadmap 2020 - using analysis mode to improve programs

[terry mcintyre]

I appreciate that Go programs are complex and not easy to tune.

Thinking over Magnus' excellent automated method ( play many games, allow early 
resignation, inspect long games ), and my own experiences, I'd like to suggest 
an additional method: when a game ends with a large loss, determine 
retroactively a) how far back the program was doomed but deluded about the 
outcome, and b) what the correct earlier plays would have been. Tune and test 
with a regression suite of difficult positions. This is like troubleshooting 
any other large and complex program; a subtle error in one portion may only 
reveal itself when a perfect storm of circumstances arises - but the bug is 
there all the time.

As Magnus and Valkyria pointed out, proper play at an earlier point in my 
example game would have destroyed Black's position. I don't feel so proud now, 
lol.

At my level of play, it is distressingly common to mis-read capturing races -- 
it's possible that a good understanding of that topic would improve Go 
programs. The difficulty cannot be understated - others have indicated that 
Hunter's Counting Liberties and Winning Capturing Races book, valuable as it 
may be, misses some cases. As Hunter observes, even dan-level players sometimes 
make mistakes in capturing races.


Programs which get semeai and seki right every time might be a few stones 
stronger. They'd certainly be more valuable as teaching tools. In the game 
above, a stronger program would have exploited my earlier weakness; this would 
have encouraged me to make better moves.

Back to Roadmap: 2020, I'd love a status map showing groups which are 
certainly alive, groups which are unstable, and groups which are certainly dead 
( assuming proper play ). That would be quite a feedback tool. When an approach 
move or throw-in threatens the status of a group, the group marker would change 
from green to blinking yellow. When the attack succeeds, the group marker would 
change to red. To be useful, this tool would have to be accurate. If not 100% 
accurate, it should at least give some indication of its level of confidence. 
Even better, especially for double-digit-kyu players, would be an exposition of 
why a group is live, dead, seki, unstable, etc. 

Terry McIntyre terrymcint...@yahoo.com


Government is an association of men who do violence to the rest of us.
- Leo Tolstoy



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Roadmap 2020 - using analysis mode to improve programs

[terry mcintyre]

I haven't got a ladder example at the moment, but here's an instance where 
Leela does not realize it is in terrible trouble.

I ( with my 8 kyu AGA rating) know with certainty by move 223 (T5) that Black 
has captured a large white group. A stronger player could read this out sooner 
than I. This fight is too big to lose for either side; nothing else on the 
board matters. ( anyone? how early is this outcome pre-ordained? )

Based on the results of its analysis mode, Leela does not recognize the outcome 
of this semeai until the large white group in the bottom right is down to two 
liberties.

 
The problem is even more stark in example2 -- similar board, black has 
foolishly played one of his own liberties for illustrative purposes. It is 
black's play, black has three liberties, white has three. Black must take away 
a liberty from white to win the capturing race, or make two eyes at T8. Black 
has only four playable moves; any other choice fails.

Leela proposes - even after several minutes of analysis and a million nodes - 
that Black should tennuki at H14. That would snatch defeat from the jaws of 
certain victory; White would dive into T8 and win the race.

I started this thread with the contention that analysis mode can help 
developers find problems, I hope this example explains why. My theory is that 
if a program could reliably recognize the outcome of such capturing races five 
or ten moves sooner, it could crush the likes of me. :D
 Terry McIntyre terrymcint...@yahoo.com


Government is an association of men who do violence to the rest of us.
- Leo Tolstoy





From: Michael Williams michaelwilliam...@gmail.com
To: computer-go computer-go@computer-go.org
Sent: Tuesday, April 21, 2009 1:57:54 PM
Subject: Re: [computer-go] Reply to Lukasz and Don + Roadmap 2020

Mention the program so that the author can either refute your claim or fix the 
bug.


terry mcintyre wrote:
 Is it reasonable to expect pro players to use 6-dan programs as a tool for 
 analysis? The pro players are markedly better - at a rough guess, a pro 
 player could give a 6 dan amateur human or program a 3 stone handicap.
 
 On the other end of the scale, beginning players and mid kyu players could 
 indeed make good use of an analysis mode by a program which is better than 
 themselves.
 
 Lastly, an analysis mode would be helpful to developers, methinks. After 
 winning a game, I like to back up a few moves and find out when the program 
 realized that it was behind. This often happens several moves after the fatal 
 blow has already been struck. I know the feeling too well, when stronger 
 players deftly skewer my group and I only discover the problem five moves 
 later. What do they know that I don't? What do they know that the program 
 doesn't?
 
 We have a saying, you learn the most from reviewing games which you have 
 lost. An analysis mode can help developers to discover when their pride and 
 joy first begins to miss the target.
  Lately, I have been playing quite a bit with a commercially available 
 program. An almost-ladder which has an extra liberty will apparently be 
 evaluated the same as a true ladder, and the program can be tricked into 
 trying to capture my ladder-like position. This sort of predictable flaw 
 might provide a clue to improve the next version.
 
 Terry McIntyre terrymcint...@yahoo.com
 
 Government is an association of men who do violence to the rest of us.
 - Leo Tolstoy
 
 
 
 
 
 ___
 computer-go mailing list
 computer-go@computer-go.org
 http://www.computer-go.org/mailman/listinfo/computer-go/

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/



  

example.sgf
Description: Binary data


example2.sgf
Description: Binary data
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Reply to Lukasz and Don + Roadmap 2020

[terry mcintyre]

Is it reasonable to expect pro players to use 6-dan programs as a tool for 
analysis? The pro players are markedly better - at a rough guess, a pro player 
could give a 6 dan amateur human or program a 3 stone handicap.

On the other end of the scale, beginning players and mid kyu players could 
indeed make good use of an analysis mode by a program which is better than 
themselves.

Lastly, an analysis mode would be helpful to developers, methinks. After 
winning a game, I like to back up a few moves and find out when the program 
realized that it was behind. This often happens several moves after the fatal 
blow has already been struck. I know the feeling too well, when stronger 
players deftly skewer my group and I only discover the problem five moves 
later. What do they know that I don't? What do they know that the program 
doesn't?

We have a saying, you learn the most from reviewing games which you have lost. 
An analysis mode can help developers to discover when their pride and joy first 
begins to miss the target.

 
Lately, I have been playing quite a bit with a commercially available program. 
An almost-ladder which has an extra liberty will apparently be evaluated the 
same as a true ladder, and the program can be tricked into trying to capture my 
ladder-like position. This sort of predictable flaw might provide a clue to 
improve the next version. 

Terry McIntyre terrymcint...@yahoo.com


Government is an association of men who do violence to the rest of us.
- Leo Tolstoy



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Could be that nobody is playing?

[terry mcintyre]

From: Jason House jason.james.ho...@gmail.com

 CGOS requires us to use new names on the server each time we change our bots. 
 It computes the strength using all games (heavilly biased with the results of 
 the first 100 games)

Hypothetically speaking, if a bot were to actually learn from experience, how 
would CGOS deal with that?


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] COGS bug in Ko detection?

[terry mcintyre]

Robert, your reference to hane-seki, also called hanezeki, was new to me, so I 
did a bit of googling. My head is now spinning; I figure that any program which 
embodies the knowledge in the following paper should be quite interesting:

http://www.goban.demon.co.uk/go/seki/hanezeki/hanezeki_abstract.pdf

 Terry McIntyre terrymcint...@yahoo.com







From: Robert Jasiek jas...@snafu.de


megasnippage hane-sekis are also pretty ugly. 



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Fast ways to evaluate program strength.

[terry mcintyre]

From: Łukasz Lew lukasz@gmail.com

I was wondering what are the good (fast/accurate) ways of evaluating
program strength.
The most accurate one is to play many games against gnugo or on KGS.
But it is quite slow as many games are needed.

Another one is to have set of labeled positions (win/loss)  and make
your program predict the labels. (This is what MoGo guys did)
It is much faster. But how well it is correlated with the true strength?


If your program were 100% accurate, it would win all winnable games. 

When any program loses a game, it would be interesting to use deeper search to 
backtrack, find the blunder which lost the game, and add key positions to the 
set. Tune your program so that it knows that move A loses, move B wins.



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Fast ways to evaluate program strength.

[terry mcintyre]

Amen to that. When using positions to judge the strength of a program, one 
would need to test not just one pro move, but a sequence of plays -- 
including some which don't appear in pro games. A pro knows how to deal 
decisively not only with the optimal plays of other pros, but also with 
suboptimal plays from the rest of us. Programs are often even stranger than 
human players. 

If I were designing a test set, I'd ask pros to defeat the program, and would 
convert the blunders into a test set. To improve, the program would have to 
generalize the lessons learned from those test cases.

 Terry McIntyre terrymcint...@yahoo.com


-- People never lie so much as after a hunt, during a war or before an 
election. -
Otto von Bismarck





From: steve uurtamo uurt...@gmail.com
To: computer-go computer-go@computer-go.org
Sent: Tuesday, April 7, 2009 5:12:27 PM
Subject: Re: [computer-go] Fast ways to evaluate program strength.

otherwise pair-go wouldn't be as funny to watch.

s.

On Tue, Apr 7, 2009 at 8:05 PM, Michael Williams
michaelwilliam...@gmail.com wrote:
 Łukasz Lew wrote:

 I would like to rephrase my question:
 Let's measure prediction of pro moves of a whole engine while
 modifying heavy playouts / MCTS in the engine.
 How well might it work?

 Probably not well.  Because what matters is not how often you play strong
 moves, but how often you avoid blunders.

 ___
 computer-go mailing list
 computer-go@computer-go.org
 http://www.computer-go.org/mailman/listinfo/computer-go/

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: RE: [computer-go] Pseudo liberties: Detect 2 unique liberties?

[terry mcintyre]

From: Heikki Levanto hei...@lsd.dk

On Fri, Apr 03, 2009 at 05:07:41PM +0200, Isaac Deutsch wrote:
   This may seem slow, but it has a couple real
   advantages. First, it works with the cache
   to maximize locality. Second it is very simple.
 
 This *does* seem slow, even when caching the number of liberties. You
 mentioned that you did this a couple years ago, do you think it still holds
 true? Thank you for the information.
 
  This is what I do too. I never bothered with bit-arrays but possibly
  that's simply because I fail to see how you can merge two chains and
  count liberties in O(1).
 
 Merging would be a simple OR operation. Counting can be done, for example,
 with some kind of binary search. Counting the bits set has been well
 researched and many different algorithms exist.

 besides, most often you only need to know if a string has zero, one, two, or
many liberties, so the counting can be aborted early.

Most cases do test for zero/one/two/many, but if we want smart playouts, it 
helps to know in advance exactly how many liberties some strings have, compared 
to others in a capturing race. Any program which assumes that n liberties is 
enough to live may be tricked by a player who can count to n+1.


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] CGT approximating the sum of subgames

[terry mcintyre]

From: Jason House jason.james.ho...@gmail.com


On Feb 17, 2009, at 4:39 PM, dave.de...@planet.nl wrote:

I've been looking into CGT lately and I stumbled on some articles about 
approximating strategies for determining the sum of subgames (Thermostrat, 
MixedStrat, HotStrat etc.)

Link?
http://www.cs.rice.edu/~cra1/Home/Publications_files/icga_vol29_4.pdf looks 
promising.

( just something I googled up )



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] static evaluators for tree search

[terry mcintyre]

From: dhillism...@netscape.net dhillism...@netscape.net

 Perhaps the biggest problem came from an unexpected quarter. MC playouts are 
 very fast and neural nets are a bit slow. (I am talking about the forward 
 pass, not the off-line training.) In the short time it took to feed a board 
 position to my net and get the results, I could have run enough MC playouts 
 to obtain a better estimate of the ownership map. :/

Would GPUs be better suited to neural nets than to MC playouts? If so, would 
this tilt the playing field in favor of neural nets on GPUs,. giving them an 
advantage over MC on  relatively fewer general-purpose CPUs? A GPU with 
hundreds of shaders is relatively cheap compared to even a handful of x86 
processors.

The same argument may apply to other forms of classification which map well to 
GPUs.





A Good Credit Score is 700 or Above. See yours in just 2 easy steps! 


  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Fuego performance

[terry mcintyre]

Does Fuego make use of multiple cores? Does it require some switch setting to 
do so?

How do I control the time used by Fuego?


  
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Poll: how long until computers are as strong as pros?

[terry mcintyre]

 From: Bob Hearn robert.a.he...@dartmouth.edu
 
 How long until a computer beats a pro -- any pro -- in an even game?
 How long until a computer can routinely beat the best pros?

We've recently seen a program with a 7 stone handicap beat a pro, so we're a 
little bit closer than when you made those computations.

I agree with David Fotland, there will be some serious algorithmic 
improvements; we are hardly scratching the surface at this point.

In addition, the computing field in general has been held back for two decades 
by excessive dependence on the x86 family of architectures; this trend is going 
to change; performance-per-million-transisters is going to rise sharply in the 
next decade. Reconfigurable computing has yet to fulfill its aims, but a 
variety of technologies are likely to come together to make it possible for 
pro-level computer programs - and a lot of other goodness - within the next 20 
years.
 
Something like SGI's Molecule and the Sicortex architectures will make it 
possible for lots of low-power minimalist computers to be clustered together at 
comparatively low cost, using less rack space and power. Today's 
commodity-based clusters waste an amazing amount of hardware. Why should a 
4000-node computer have 1000 VGA ports, 1000 disk drives, 1000 disk 
controllers, 1000 power supplies? We need to create commodity compute modules 
which are a lot leaner, smaller, cheaper, faster, and more efficient. A compute 
node should have one or many CPUs, memory controllers, fast inter-node 
communications, local flash (or a succesor thereof) for boot and other 
longer-term info, and nothing else - no video, no disk, no independent fans and 
power supplies, etc. It could fit in a matchbox. A large cluster should fit in 
a breadbox.

 Not a very scientific poll, I realize, but I'd like some numbers to use in my 
 AAAS talk on Saturday.
 
 FWIW, this is a back-of-the-envelope calculation I did in August, when MoGo 
 beat 
 Myungwan Kim 8p at H9:
 
  After the match, one of the MoGo programmers mentioned that doubling the 
 computation led to a 63% win rate against the baseline version, and that so 
 far 
 this scaling seemed to continue as computation power increased.
  
  So -- quick back-of-the-envelope calculation, tell me where I am wrong. 63% 
 win rate = about half a stone advantage in go. So we need 4x processing power 
 to 
 increase by a stone. At the current rate of Moore's law, that's about 4 
 years. 
 Kim estimated that the game with MoGo would be hard at 8 stones. That 
 suggests 
 that in 32 years a supercomputer comparable to the one that played in this 
 match 
 would be as strong as Kim.
  
  This calculation is optimistic in assuming that you can meaningfully scale 
  the 
 63% win rate indefinitely, especially when measuring strength against other 
 opponents, and not a weaker version of itself. It's also pessimistic in 
 assuming 
 there will be no improvement in the Monte Carlo technique.
  
  But still, 32 years seems like a surprisingly long time, much longer than 
  the 
 10 years that seems intuitively reasonable. Naively, it would seem that 
 improvements in the Monte Carlo algorithms could gain some small number of 
 stones in strength for fixed computation, but that would just shrink the 32 
 years by maybe a decade.
 
 
 Thanks,
 Bob Hearn
 
 -
 Robert A. Hearn
 Neukom Institute for Computational Science, Dartmouth College
 robert.a.he...@dartmouth.edu
 http://www.dartmouth.edu/~rah/
 
 
 ___
 computer-go mailing list
 computer-go@computer-go.org
 http://www.computer-go.org/mailman/listinfo/computer-go/



  
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] GPGPU

[terry mcintyre]

- Original Message 

 From: Petr Baudis pa...@ucw.cz

   There has been some talk about implementing monte-carlo playouts on
 GPUs in the past, I have heard rumours about Polish bachelor student
 doing libego - GPGPU conversion as a project, etc. but I know of
 nothing concrete ever materializing - is anybody aware of anything?
 
   We have recently bought very high-end nVidia card at our university
 department for trying out GPGPU and I'm thinking of a little project for
 myself, maybe...
 
   I'm not much skilled in this kind of programming though, so I'm not
 quite sure what the best design approach to take would be... my current
 ideas so far are either
 
   (i) Have one game per pipeline, and in each cycle, take a board and
 transform it by playing a random move (or possibly have an extra cleanup
 cycles if capturing stones would take too long); you should be able to
 do some neat pattern matching and so too
 
   (ii) Have one intersection per pipeline, in one cycle play a random
 move, then have board_height cycles for captures and liberty updates
 to ripple through to all the neighbors. The code would be much more
 streamlined, but I'm not sure yet if there is a good way to do the
 rippling - ORing bitmaps?
 
   I guess there is a lot of things to try out.

There may be ways to implement monte carlo effectively on GPUs - but some other 
algorithms might make more effective use of the different capabilities of the 
GPU. For instance, neural networks might map well to a GPU. It might also be 
possible to collect a lot of useful information about shapes using cellular 
automata. 

The GPU might be the main engine, or it might be deployed to collect 
information about the current board situation ( such as the most interesting 
plays ) which is then fed to the CPU for creation of a tree structure. 

Hard to say a priori -- lots of room for experimentation!


  
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] time measurement

[terry mcintyre]

I would not want to discourage remote players - some systems are designed to 
take advantage of large supercomputers which are not very portable.

However, remote players need to accept the trade-off. They get to avoid the 
trouble of packing up and shipping a trailer full of computer gear to the other 
side of the world. The downside is that network lag happens.

As others have mentioned, client-side timing can be gamed by the simple 
expedient of pulling the plug to the modem; I can think of a few ways to 
manipulate iptables which would have similar effects.

I hope that tournament organizers do their best to provide a decent connection. 
Remote participants need to do likewise. 



  
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] time measurement

[terry mcintyre]

This is the timeseal web site:

http://www.unix-ag.uni-kl.de/~chess/soft/timeseal/

Looks like an interesting read.

 Terry McIntyre terrymcint...@yahoo.com


-- Libertarians Do It With Consent!



- Original Message 
 From: Jeff Nowakowski j...@dilacero.org
 To: computer-go computer-go@computer-go.org
 Sent: Tuesday, February 3, 2009 10:34:32 AM
 Subject: Re: [computer-go]  time measurement
 
 On Tue, 2009-02-03 at 10:16 -0800, Ian Osgood wrote:
  Frankly, I'm baffled that nobody in the online Go world cares about  
  network lag. Timeseal has been a mature technology on the chess  
  servers for over a decade.
 
 I logged into FICS today for nostalgia and one of the first thing I see
 is somebody complaining on channel 53 about somebody lag cheating.
 It's just a can of worms to require some proprietary binary that people
 have to use, trust, and believe is unhackable.  And remember, pulling
 your network cable from the wall is an unstoppable hack.
 
 -Jeff
 
 ___
 computer-go mailing list
 computer-go@computer-go.org
 http://www.computer-go.org/mailman/listinfo/computer-go/



  
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] time measurement

[terry mcintyre]

- Original Message 

 From: Gian-Carlo Pascutto g...@sjeng.org
 
 Heikki Levanto wrote:
 
  No amount on crypto-mumbo-jumbo will solve the problem that the server will
  have to trust the program, and its author. Signing can provide some little
  assurance that the program running today is the same as was running
  yesterday, but that's about all. As long as we can write our own programs,
  there is no way to stop us from cheating in them, intentionally or by
  accident.
 
 Very true.
 
 To the people that point to timeseal on the chess servers: both the
 binaries and the protocol itself are trivially reverse engineerable. I
 know of at least 2 people (not counting myself) who have done this.
 
 Because the client side is fully under your control, you can cheat all
 you want with this system. But you can also write a client for a
 non-supported platform :)
 
 The only reason why this doesn't create more problems is that the people
 who have the ability to do this reverse engineering usually have better
 things to do with their time than to cheat on chess servers.
 
 It's like copy protections: it stops some people, but it sure as hell
 ain't secure in any meaningful sense.

So it's trustworthy enough the people accept it as a palliative for net lag, in 
an environment where most people can be trusted. From browsing chess-specific 
web sites, there are customs and procedures for dealing with cheats. In this 
day and age, unless you're in the boonies, only so much net lag is believable.

Preserving one's reputation is a good enough incentive for most people to do 
the right thing.



  
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] time measurement

[terry mcintyre]

Further information, including a helpful diagram:

http://www.edcollins.com/chess/lag.htm


 Terry McIntyre terrymcint...@yahoo.com


-- Libertarians Do It With Consent!



- Original Message 
 From: terry mcintyre terrymcint...@yahoo.com
 To: computer-go computer-go@computer-go.org
 Sent: Tuesday, February 3, 2009 10:59:12 AM
 Subject: Re: [computer-go]  time measurement
 
 This is the timeseal web site:
 
 http://www.unix-ag.uni-kl.de/~chess/soft/timeseal/
 
 Looks like an interesting read.
 
 Terry McIntyre 
 
 
 -- Libertarians Do It With Consent!
 
 
 
 - Original Message 
  From: Jeff Nowakowski 
  To: computer-go 
  Sent: Tuesday, February 3, 2009 10:34:32 AM
  Subject: Re: [computer-go]  time measurement
  
  On Tue, 2009-02-03 at 10:16 -0800, Ian Osgood wrote:
   Frankly, I'm baffled that nobody in the online Go world cares about  
   network lag. Timeseal has been a mature technology on the chess  
   servers for over a decade.
  
  I logged into FICS today for nostalgia and one of the first thing I see
  is somebody complaining on channel 53 about somebody lag cheating.
  It's just a can of worms to require some proprietary binary that people
  have to use, trust, and believe is unhackable.  And remember, pulling
  your network cable from the wall is an unstoppable hack.
  
  -Jeff
  
  ___
  computer-go mailing list
  computer-go@computer-go.org
  http://www.computer-go.org/mailman/listinfo/computer-go/
 
 
 
   
 ___
 computer-go mailing list
 computer-go@computer-go.org
 http://www.computer-go.org/mailman/listinfo/computer-go/



  
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] RAVE and memory allocation considerations

[terry mcintyre]

 From: Isaac Deutsch i...@gmx.ch
 
 Do you think the spent allocating could be critical?
 What do you think would be a good way to deal with this? I think to avoid the 
 continuous allocation/deallocation,
 it's necessary to keep the threads running instead of creating/joining them 
 for 
 each genmove. This would
 allow them to only have to alloc/dealloc when the board size is changed.

If your threads persist from move to move, you will save not only the
expense of allocating and deallocating a large memory pool, but also the
cost of creating new processes.


On the other hand, you will need a quick method of clearing old information 
from previous nodes.
 
Terry McIntyre terrymcint...@yahoo.com

-- Libertarians Do It With Consent!


  
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: GCP on ICGA Events 2009 in Pamplona

[terry mcintyre]

I found a Mind Sports slide presentation which says the following:

Go originated in South-East Asia, and the majority of Go players and fans 
will be found in that area.
Private initiative characterises the organisation of Go which explains the 
strong ties with the media
and business.
GO is well recognized by Asian people  institutions
  In China, the government strongly supports the organisation and 
promotion of Go.
  In Japan Go is recognised as an instrument contributing to key 
elements of human life, such as
  young people’s education, leisure activities, mental care for the 
aged, promotion of culture.
  In Korea the demand for Go is rising rapidly. A number of Korean 
youngsters are the top
  players in the world. They are role models for the Korean youth. In 
many schools Go is part of
  the curriculum.
Many Go teachers and promoters have travelled around the world and 
popularised the game of Go.
Nowadays, Go is heavily broadcast in Asia:
15 Chinese television networks. Go broke record of TV viewers on CCTV.
3 Korean TV channels are dedicated solely to GO.
Japan’s National Station (NHK) organises a tournament running throughout 
the year which is
broadcast for two hours every Sunday, attracting a very large audience.


Mind Sports claims there are 60 million Go players and 300 million chess 
players worldwide.

The usgo.org site claims that there are 100 million go players worldwide. 

I have been told by a Korean professional that the popularity of Baduk in Korea 
is rising quite rapidly.

Terry McIntyre terrymcint...@yahoo.com


-- Libertarians Do It With Consent!



___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/