Re: [computer-go] low-hanging fruit - yose

[Olivier Teytaud]

2. Mogo (and CrazyStone) are using lots of intelligence in their
playouts, and that is the cause of the nakade weakness. They are good
players, but they have preconceptions. They consider the moves required
to discover the difference between a nakade and
dead-stones-in-a-definitely-alive-group as low priority. So, in that
sense, they do have a concept of nakade.


There's more Go-expertise tricks in crazystone than in mogo, as far as
I see in Remi's papers. The Go-expertise in mogo is a very (possibly 
too much) small number of lines of codes.


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

Re: [computer-go] low-hanging fruit - yose

[Darren Cook]

>> Any estimate of winning probability is only as good as the estimates of
>> whether particular games are actually won or lost.
>>
>> Evidently, even strong programs fail to recognize the impact of nakade,
> 
> MC programs don't even have any concept of nakade.  Nevertheless, the
> best of them are stronger than programs that do.

Just replying to this point, not the main theme of the thread, but there
are two things here:

 1. Random playout MC/UCT programs have no concept of nakade. But they
don't have the nakade weakness either. They are bad players, but pure.

 2. Mogo (and CrazyStone) are using lots of intelligence in their
playouts, and that is the cause of the nakade weakness. They are good
players, but they have preconceptions. They consider the moves required
to discover the difference between a nakade and
dead-stones-in-a-definitely-alive-group as low priority. So, in that
sense, they do have a concept of nakade.

(I hope Remi, or one of the Mogo developers, will correct me if I've
misunderstood what is going on.)

Darren


-- 
Darren Cook
http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary)
http://dcook.org/work/ (About me and my work)
http://dcook.org/work/charts/  (My flash charting demos)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] GPUs and go algorithms?

[Darren Cook]

Joshua Shriver wrote:
> I've been looking into GPGPU for several years now, there was even some buzz
> in the comp-chess stream but the downsides seemed to be to much. Think the
> big problem is the latency on the PCI/AGP bus. Though that might not be as
> much an issue now with PCI-x, etc.

Thanks. My question could've been rephrased as "Can a basic alpha-beta
searcher for chess be written to run on a GPU?". Can I take the above to
mean "Yes, but the overhead of calling it took too much time"? Or were
they putting some smaller part of the chess algorithm (e.g. leaf node
evaluation or move sorting) on the GPU? (In which case I can see how
communication overhead would drown out the performance gain.)

> For more info I'd refer you to this site which has been using GPU's for
> years.
> http://www.gpgpu.org/

Thanks, yes, that is a useful site. However I don't see anything related
to tree search.

Darren

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

Re: [computer-go] GPUs and go algorithms?

[Joshua Shriver]

I've been looking into GPGPU for several years now, there was even some buzz
in the comp-chess stream but the downsides seemed to be to much. Think the
big problem is the latency on the PCI/AGP bus. Though that might not be as
much an issue now with PCI-x, etc.

For more info I'd refer you to this site which has been using GPU's for
years.
http://www.gpgpu.org/

-Josh

On Dec 6, 2007 7:32 PM, Darren Cook <[EMAIL PROTECTED]> wrote:

> An interesting article on using GPUs for general purpose computation:
>
> http://www.linux-mag.com/microsites.php?site=business-class-hpc&sid=build&p=4543
>
> In (current mainstream) computer go there are two main CPU-bound
> algorithms: playouts (random, or incorporating logic or patterns) and
> tactical search. But the GPUs seem even more restricted in what they can
> do than the PS3 Cell processors (where the main restriction there was
> only a small amount of local memory). E.g. from the above article:
>* No stack or heap
>* No integer or bit-wise operations
>* No scatter operations (a[i]=b)
>* No reduction operations (max(), min(), sum())
>
> On the other hand this quote [1] from the Sh language page says it has
> for/if statements, which the latest GPUs support.
>
> Does anyone here both understood the above go algorithms *and* had
> experience with programming GPUs, and can confirm that they are not
> really useful?
>
> Darren
>
>
> [1]: From http://www.libsh.org/about.html
> Sh incorporates full language constructs for branching (e.g. for loops
> and if statements). Once GPUs are powerful enough to execute such
> constructs (which, to some extent, is true today) backends can be
> adjusted to compile such code to real hardware assembly. In the mean
> time our GPU simulator Sm implements various features expected to be in
> GPUs in the near future, such as a unified vertex and fragment
> instruction set.
>
>
> --
> Darren Cook
> http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary)
> http://dcook.org/work/ (About me and my work)
> http://dcook.org/work/charts/  (My flash charting demos)
> ___
> 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] GPUs and go algorithms?

[Darren Cook]

An interesting article on using GPUs for general purpose computation:
http://www.linux-mag.com/microsites.php?site=business-class-hpc&sid=build&p=4543

In (current mainstream) computer go there are two main CPU-bound
algorithms: playouts (random, or incorporating logic or patterns) and
tactical search. But the GPUs seem even more restricted in what they can
do than the PS3 Cell processors (where the main restriction there was
only a small amount of local memory). E.g. from the above article:
* No stack or heap
* No integer or bit-wise operations
* No scatter operations (a[i]=b)
* No reduction operations (max(), min(), sum())

On the other hand this quote [1] from the Sh language page says it has
for/if statements, which the latest GPUs support.

Does anyone here both understood the above go algorithms *and* had
experience with programming GPUs, and can confirm that they are not
really useful?

Darren


[1]: From http://www.libsh.org/about.html
Sh incorporates full language constructs for branching (e.g. for loops
and if statements). Once GPUs are powerful enough to execute such
constructs (which, to some extent, is true today) backends can be
adjusted to compile such code to real hardware assembly. In the mean
time our GPU simulator Sm implements various features expected to be in
GPUs in the near future, such as a unified vertex and fragment
instruction set.


-- 
Darren Cook
http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary)
http://dcook.org/work/ (About me and my work)
http://dcook.org/work/charts/  (My flash charting demos)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] winning a won game

[Nick Wedd]

In message <[EMAIL PROTECTED]>, terry mcintyre 
<[EMAIL PROTECTED]> writes

I am hardly fit to clean the dust from Pro 9-dan Go Seigen's goban, so
I'll just rest my argument


What _is_ your argument?

Nick


with the chapter headings from his book,
Winning a Won Game:
Chapter 1 Three Golden Rules
  *Avoid uncertainties when you have the lead
  *Seize the opportunity when it is presented
  *Attack the opponent's weakness and deliver the fatal blow
Chapter 2 Seven Examples of Success
  *Avoid battle while ahead
  *Grasp the opportunity and attack vigorously
  *Claim victory by invading
  *Counterattack when your opponent tries to claim victory
  *Do not back off even slightly in close games
  *Do not let any opportunity slip away
  *Use the splitting attack
What's good enough for him, should be fair enough for the rest of us
... now to determine who to convert these maxims to robust code.


Looking for last minute shopping deals? Find them fast with Yahoo!
Search.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/


--
Nick Wedd[EMAIL PROTECTED]
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] winning a won game

[Don Dailey]

Hi Terry,

How to convert these maxims to robust code?   Use monte carlo with
win/loss scoring as we do now.These maxims fit the monte carlo
scoring model perfectly.

- Don



terry mcintyre wrote:
> I am hardly fit to clean the dust from Pro 9-dan Go Seigen's goban, so
> I'll just rest my argument with the chapter headings from his book,
> Winning a Won Game:
>
> Chapter 1 Three Golden Rules
>
> * Avoid uncertainties when you have the lead
> * Seize the opportunity when it is presented
> * Attack the opponent's weakness and deliver the fatal blow
>
> * Chapter 2 Seven Examples of Success Avoid battle while ahead
> * Grasp the opportunity and attack vigorously
> * Claim victory by invading
> * Counterattack when your opponent tries to claim victory
> * Do not back off even slightly in close games
> * Do not let any opportunity slip away
> * Use the splitting attack
>
> What's good enough for him, should be fair enough for the rest of us
> ... now to determine who to convert these maxims to robust code.
>
>
> 
> Looking for last minute shopping deals? Find them fast with Yahoo!
> Search.
> 
>
> 
>
> ___
> 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] winning a won game

[Chris Fant]

I propose a far more powerful and correct set of rules:

1.  Play the move that gives you the best chance of winning.

Unfortunately, that it not very helpful for humans.  Luckily it is
helpful for a UCT engine or a similar best first + MC engine.


On Dec 6, 2007 6:29 PM, terry mcintyre <[EMAIL PROTECTED]> wrote:
>
> I am hardly fit to clean the dust from Pro 9-dan Go Seigen's goban, so I'll
> just rest my argument with the chapter headings from his book, Winning a Won
> Game:
>
>  Chapter 1 Three Golden Rules
>  Avoid uncertainties when you have the lead
>  Seize the opportunity when it is presented
>  Attack the opponent's weakness and deliver the fatal blow
> Chapter 2 Seven Examples of Success
>  Avoid battle while ahead
>  Grasp the opportunity and attack vigorously
>  Claim victory by invading
>  Counterattack when your opponent tries to claim victory
>  Do not back off even slightly in close games
>  Do not let any opportunity slip away
>  Use the splitting attack What's good enough for him, should be fair enough
> for the rest of us ... now to determine who to convert these maxims to
> robust code.
>
>
>  
> Looking for last minute shopping deals? Find them fast with Yahoo! Search.
> ___
> 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] Gnugo rank on 9x9 on kgs

[Alain Baeckeroot]

Le jeudi 6 décembre 2007, Don Dailey a écrit :
> 
> Lavergne Thomas wrote:
> > If some bot can be setup to play on kgs for enough time to get a solid
> > rank and then put on cgos to get an elo rating with the same
> > configuration we could find a formula to convert elo to kgs ranks.
> > For sure, this is not perfect but I think is good enought.
> >   

> But most of us feel that you cannot do this with GO programs - you need
> humans.   For instance you could take GnuGo,  get a 19x19 rating and
> then play on 9x9 CGOS and use it as a reference point.However GnuGo
> was not designed to play 9x9 go.   My own program Lazarus is terrible at
> 19x19 but pretty good at 9x9.   It could probably give a low kyu player
> a really good game on 9x9 but it would be easily beat at 19x19 - so it's
> not a good way to standardize.I believe GnuGo is more balanced in
> this way - but it's probably a bad idea in general to figure it this way.
> 
> Your idea is fine for 19x19 CGOS.  
> 
> - Don

I used 946 9x9 games of my gnugo bot on kgs:
On 9x9 it appears that gnugo _has_ the same rank as on 19x19.
So just giving standard gnugo a fixed kyu on cgos (lets say 6k like kgs)
should give rather good estimation.

/Alain

PS: Here are the histograms for my ranked bots on kgs, for those who wants
to do more subtle estimation and cannot wait monthes before their bot
gathered enough games on kgs :)

(these are old games before ranking system changes, so gnugo 3.7.9 and 10
 were 13k kgs, they are now 6k)

I filtered out handicap games and unfinished, but did not check cheaters.

The tables are  #occurence #opponent_rank(kgs_old_kyu)

For komi 7 and 7.5
gg99_rank/km7$ cat black_lose_agaisnt.csv
  1 2
  1 10
  2 13
gg99_rank/km7$ cat black_wins_agaisnt.csv
  1 10
  1 12
  2 13
gg99_rank/km7$ cat white_wins_agaisnt.csv
  1 2
  3 9
  1 10
  1 11
 19 12
 44 13
  2 15
  4 16
  3 18
  2 19
  1 20
  2 21
  2 25
  2 26
  4 30
gg99_rank/km7$ cat white_lose_agaisnt.csv
  1 3d
  1 2
  5 9
  2 10
  1 11
  4 12
 47 13
  1 14
  2 16
  1 17
  2 18
  1 19
  1 21
  2 25
  6 30

For komi 0 and 0.5 :
gg99_rank/km0$ cat black_wins_agaisnt.csv
  1 5
  1 6
 13 7
 14 8
 16 9
 11 10
 34 11
 50 12
  2 14
  3 17
  1 18
  1 24
  1 30
gg99_rank/km0$ cat black_lose_agaisnt.csv
  1 3
  1 4
  2 5
  1 6
  6 7
 11 8
 17 9
  5 10
 23 11
 23 12
  1 17
  1 20
gg99_rank/km0$ cat white_wins_agaisnt.csv
 28 12
211 13
  5 25
  1 30
gg99_rank/km0$ cat white_lose_agaisnt.csv
 31 12
245 13
  1 14
  2 16
  1 17
  1 22
  4 25

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

[computer-go] winning a won game

[terry mcintyre]

I am hardly fit to clean the dust from Pro 9-dan Go Seigen's goban, so I'll 
just rest my argument with the chapter headings from his book, Winning a Won 
Game:


Chapter 1 Three Golden Rules



Avoid uncertainties when you have the lead

Seize the opportunity when it is presented

Attack the opponent's weakness and deliver the fatal blow
Chapter 2 Seven Examples of Success



Avoid battle while ahead

Grasp the opportunity and attack vigorously

Claim victory by invading

Counterattack when your opponent tries to claim victory

Do not back off even slightly in close games

Do not let any opportunity slip away

Use the splitting attack
What's good enough for him, should be fair enough for the rest of us ... now to 
determine who to convert these maxims to robust code. 




  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: evaluating monte carlo results

[dhillismail]

> -Original Message-
> From: Jason House <[EMAIL PROTECTED]>
> To: computer-go 
> Sent: Thu, 6 Dec 2007 4:44 pm
> Subject: Re: [computer-go] Re: evaluating monte carlo results



> On Dec 6, 2007 4:22 PM, <[EMAIL PROTECTED]> wrote:

> > 
> > My program is riddled with code to try and make use of this. (It's always 
> > bothered me that UCT relies on the
?> > standard deviation of (often) multi-modal distributions.) It hasn't made 
my engine any stronger but it has helped?
 > > me understand some things better. 




> Care to elaborate on what you've come to learn?? I too have discomfort with 
> some of the ways UCT works.


If I start from an empty board and make a histogram of the final scores of 
random playouts, it tells me a bit about my playout algorithm. Smarter playout 
algorithms lead to lower (IIRC) required komis. 

>From a root node, looking at the tails of the histogram of final scores tells 
>me something about how much can potentially be gained by applying the mercy 
>rule and where to set the threshold.

It seems reasonable to suppose that for a root node where the distribution of 
outcomes is changing rapidly (the peaks moving around) or has widely separated 
peaks, maybe it should still be exploring more, or maybe it just needs more 
time, this turn, to settle. I personally haven't gotten any traction here but 
wouldn't be too surprised if someone else has more luck.

It gets into issues of whether any margin of victory is very significant. I 
notice the "why don't we make UCT just a little greedier" discussion has 
cropped up yet again. I've tried that both ways, as have many others here.




More new features than ever.  Check out the new AIM(R) Mail ! - 
http://o.aolcdn.com/cdn.webmail.aol.com/mailtour/aol/en-us/text.htm?ncid=aimcmp000501
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: low-hanging fruit - yose

[Don Dailey]

You example is perfect for explaining the strengths of Monte Carlo.

And I think your analysis is wrong.   A Monte Carlo program will choose
the group that maximizes it win expectancies.   If it see's all groups
as 85%  then it would clearly go for the biggest group since that has a
bearing on the probability of winning.

The beauty of it is that if you have a complicated situation such as
yours,  but imagine each group has different odds of survival and there
are many of them of different sizes.   A human will probably take the
naive approach of immediately defending the largest group because that
is often the right choice. Or he will intuitively choose the move
that is ON AVERAGE going to win the most stones.   

But the monte carlo engine takes a more measured and intelligent
approach.  It does a pragmatic calculation to determine which exact move
gives it the best chances of winning the game.What less are you
asking for? 

And it's not STUPID about this.   Usually the biggest group is the one
you want and it's not like the monte carlo programs purposely will go
after the little group - they are not trying to minimize their score as
some people seem to believe. 

They are doing what every player should be doing - maximize your winning
chances.   It's irrelevant whether they are good at this or not or if
they make mistakes that cause them to lose games - the point is that
they are focused on the only goal of winning to the best of their
ability.  It's just plain silly to focus on a less relevant goal and I
don't understand the compulsion to make them play for less worthy
goals.   If it made them play stronger - then sure - go for it.  But it
doesn't work that way.

I rather like this style of play.When the game is over and you have
lost,  I think it makes you look like a chump to fight as if you still
believe you are winning. And even more I think trying to win big
makes you look like  a fool - at least it makes you look arrogant. I
remember as immature children we would get upset if our opponents
resigned (at chess.)   We wanted the thrill of victory.And it wasn't
good enough to just checkmate them,  we had to wipe out every piece and
pawn and then proceeded to checkmate them. As an adult you want to
move on to the next game - this one is played out and no longer
interesting.   Monte Carlo programs are like this - the game is no
longer interested and they don't pretend it is.

With the greedy approach you recommend,  it's possible that you could
convert some losses to wins - but you have to program the machine first
to win less!   There is little point in that.
 

- Don



Dave Dyer wrote:
> Here's a more likely scenario: Approaching endgame, there
> are 10 "resolved" fights that remain to be played out.  The
> program estimates is won 5 of them and lost 5 of them,
> each with 85% confidence.  The sizes of the groups is
> such that any single switch from won to lost will swing
> the game.  The probability of one such flip is pretty high.
>
> If one of the groups is much larger, you should go for the big
> group, because if it switches, the game is flipped irrevocably,
> whereas if one of the small groups flips, it might be corrected
> by switching status of another group. 
>
> That's why you should play for the big win, or to avoid the
> big loss.  It swamps all the other uncertainties.
>
> Of course, current programs don't see the situation with
> anything approaching this level of analysis, but given
> a choice or a big win or a small win with slightly higher
> probability, I suspect that detailed analysis would be
> similar to the above.
>
> ___
> 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] programs at the US Go Congress

[David Fotland]

I organized the go congress computer go tournaments for many years.

Ask the AGA congress organizers for prize money.  The congress has a big
pool of prize money.  Several years I convinced the organizers to put up
$500 to $1000 in prize money.  Usually the congress budget isn't set until
right before it starts, so they never committed to prize money until the
start of the congress.

Ask the congress organizer about machines.  The congresses are at colleges,
which will have computer labs.  Sometimes they are willing to let us use the
computer lab for a couple of days.  Most participants brought their own
machine in the more recent years, after laptops became inexpensive, so you
might not need computers.

I used to run the tournament on Monday and Tuesday, since Wednesday is a day
off, and an early tournament lets the go players concentrate on the congress
human tournaments after the go tournament is over.  I ran a round robin or
double round robin.  That way you can start games as soon as opponents are
ready and the tournament is over much quicker.

I suggest publishing rules ahead of time to avoid conflicts, and appoint
someone to be tournament director in case of disputes.  You should probably
plan to support both modem protocol and gtp.  Gtp requires a referee
computer, so you will have to bring one extra.

I plan to go to the European congress in Sweden, which should have a
computer competition.  I think it conflicts with the US congress, so I don't
think I'll be there.

David  

Here is the rules and announcement from the last tournament I organized:

1996 UNITED STATES COMPUTER GO CHAMPIONSHIP
.S -2
.R

This announces the 1996 U.S. Computer Go Competition.

The 1996 US Computer Go Championship will take place at the 16th annual
US Go Congress, on July 21, 22, 23rd, at John Carrol University, in
Cleveland, Ohio. 

This is an excellent opportunity to meet and compete with others interested 
in Computer Go.

A plaque or trophy and title of US Computer Go Champion will be awarded
to the winner.  There is no cash prize.  This tournament is not affiliated
with the World Computer Go Congress, although the rules and format are
very similar.

In 1988 and 1989 Acer ran the US Preliminaries to the World Computer
Go Congress at the US Go Congress.  In 1990 they changed their
procedure to have a mail in preliminary in Taiwan.  The United States
Computer Go Championship was organized to ensure that there continues
to be an annual computer go competition in North America.  The informal
discussions and contacts during the tournament help increase the strength
of all the programs.  This will be the seventh United States Computer Go
Championship.  Last year 4 programs participated.  Typically 5 to 7 
programs compete.


.
ENTERING THE CONTEST:
.
You must register for the US Go Congress to enter the Computer Go
Competition.

Please contact David Fotland as soon as possible if you plan to participate.
There is no penalty for withdrawing from participation later.  I prefer
early notice of participation, but will accept new participants up
to the day before the competition.

For additional information on the Computer Go contest, contact:

David Fotland
4863 Capistrano Ave
San Jose Ca 95129-1031
(408)985-1236
E-mail: [EMAIL PROTECTED]

RULES

Contestants must provide their own computer, which must be present at the 
contest site.  All transportation costs and risks will be borne by the
contestant.  There will be a locked room for the contest, but the
Congress will not be responsible for the safety of any equipment left there.

This year there may be some computer hardware available, but at this time
I can't promise anything.

Any Go program can participate in the contest, but only US programs whose
author(s) are US residents are eligible for the title of US Computer Go
Champion.  The title of North American Open Computer Go Champion will be
awarded to the program that finishes first, no matter where it is from.
Each program can only be registered once.  

Play is governed by the SST laws of Go (GOE) published by the Ing Chang Chi
Wei Chi Educational foundation.  In summary, the score is territory plus
live stones (prisoners don't count), suicide of more than one stone
is allowed, repetition is forbidden, surrounded territory in a seki 
counts as points.  Black plays first and gives 8 points komi at the end of
the 
game.  If a program makes an illegal move it loses.  
Mirror Go is not allowed past move number 60.
Any rule disputes will be settled by the tournament referee.

There will be a Go board between the computers which will have the official
game position.  If a move is entered incorrectly the problem may be fixed
while the clock is running.  If the participant is unable to correct his
program to agree with the position on the Go board, the participant loses.

Programs should
be able to remove dead stones from the screen or demonstrate that
the dead stones are recognized at the end of the game.  If both programs
pass

Re: [computer-go] low-hanging fruit - yose

[terry mcintyre]

You can't "play to win" if you don't actually know whether you are winning or 
losing.

Analyze any lost game, and the loser will admit "I didn't see that coming" -  
they were playing 
an imaginary game, not the one actually on the board. Some are honest enough to 
admit: "I was hallucinating there."

We're not talking about 85% of this and 80% of that; we're talking about groups 
which are 100% dead, irrefutably dead, 
get  the casket and buy the flowers and fire the salutes, it's smelling rotten 
already, versus programs which assign a 90% 
estimation of winning the game, buying fireworks and Xmas presents to celebrate 
for this move and the next until ...

Ooops! Is my witty bitty group dead? Whatever were we thinking?

 
Terry McIntyre <[EMAIL PROTECTED]>
They mean to govern well; but they mean to govern. They promise to be kind 
masters; but they mean to be masters. -- Daniel Webster




  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: low-hanging fruit - yose

[Dave Dyer]

Here's a more likely scenario: Approaching endgame, there
are 10 "resolved" fights that remain to be played out.  The
program estimates is won 5 of them and lost 5 of them,
each with 85% confidence.  The sizes of the groups is
such that any single switch from won to lost will swing
the game.  The probability of one such flip is pretty high.

If one of the groups is much larger, you should go for the big
group, because if it switches, the game is flipped irrevocably,
whereas if one of the small groups flips, it might be corrected
by switching status of another group. 

That's why you should play for the big win, or to avoid the
big loss.  It swamps all the other uncertainties.

Of course, current programs don't see the situation with
anything approaching this level of analysis, but given
a choice or a big win or a small win with slightly higher
probability, I suspect that detailed analysis would be
similar to the above.

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

Re: [computer-go] Re: evaluating monte carlo results

[Jason House]

On Dec 6, 2007 4:22 PM, <[EMAIL PROTECTED]> wrote:

>
> My program is riddled with code to try and make use of this. (It's always
> bothered me that UCT relies on the standard deviation of (often) multi-modal
> distributions.) It hasn't made my engine any stronger but it has helped me
> understand some things better.


Care to elaborate on what you've come to learn?  I too have discomfort with
some of the ways UCT works.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] low-hanging fruit - yose

[Don Dailey]

terry mcintyre wrote:
> Any estimate of winning probability is only as good as the estimates
> of whether particular games are actually won or lost.
So what?   This is about the sophistication of the approach you are
using.   Monte Carlo programs use the sophisticated approach of viewing
the game globally and to consider what they need to do to win.   I
cannot believe anyone is still suggesting that they just pick off
whatever they can and hope for the best.

Here is an example of why this works so well and why your greedy
approach is so wrong:

   Consider a position where there are 2 groups left that are being
fought over.  One of these groups is very large and the other is quite
small.The computer must win one of these groups or it will lose the
game - but if it wins either group it wins the game.The computer
estimates that attacking the huge group will result in an impressive win
with 80% confidence,   but attacking the small group will result in a
"tiny" win with 85% confidence.   

The way you guys are thinking,  the big group is the way to go - somehow
you must be imagining that it gives you a greater chance of winning the
game (because it's a much bigger group.) But if either attack fails,
you lose.  Clearly, attacking the small group gives you a better
chance of winning.

But you say, "what if the computer doesn't reliably estimate this and
it's wrong?"Well,  I'm sure it will make a lot of wrong estimates, 
but does that change anything?Does that justify it abandoning the
strategy of trying to win?

Monte Carlo play-outs are where these programs get their scoring
estimates.  If they are wrong, you can blame the play-outs.   If you
decide to count stones instead of wins,  you are still subject to
error.

There is a fundamental difference, which apparently isn't obvious to
some of us, between playing to win and playing for stones.   These are 2
conflicting goals and like anything else in life, if you have
conflicting goals both goals suffer.

There is only one way around this - if you can give one goal complete
priority.   Many of us have tried to incorporate both goals and I have
not heard of anyone yet having success.

If you believe you can have your cake and eat it too,  then you are
really saying that you don't believe these goals conflict. But we
have already proved they conflict.   Change your program to count stones
instead of wins and see what happens.  

- Don



>
> Evidently, even strong programs fail to recognize the impact of
> nakade, which will alter the score not by one point, but by ten or
> twenty.  Their estimate of winning probability is totally wrong. Good
> players winnow out losing moves and stick with good moves - the basic
> premise of minimax searching. Losing a big group will lead to a win
> only if one obtains equivalent compensation elsewhere. Good players
> sometimes make sacrifice plays, but failing to recognize that one's
> group is lost will totally skew one's estimate of one's winning chances.
>
>
>
> 
> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try
> it now.
> 
>
> 
>
> ___
> 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] low-hanging fruit - yose

[Chris Fant]

Go ahead and do it then and produce this super-bot.  I know that the
programmers of the top engines have tried many things that have
weakened the engine.  This could just as easily be one of those as it
could be one that improves it.  Maybe even easier.  Only way to tell
is to try it out (with bug-free code).


On Dec 6, 2007 4:20 PM, terry mcintyre <[EMAIL PROTECTED]> wrote:
>
>
> From: Nick Wedd <[EMAIL PROTECTED]>
>
>
> >>which will alter the score not by one point, but by ten or twenty.
> >>Their estimate of winning probability is totally wrong. Good players
> >>winnow out losing moves and stick with good moves - the basic premise
> >>of minimax searching. Losing a big group will lead to a win only if one
> >>obtains equivalent compensation elsewhere. Good players sometimes make
> >>sacrifice plays, but failing to recognize that one's group is lost will
> >>totally skew one's estimate of one's winning chances.
>
> >We all know that MC programs don't play perfectly.  What point are you
> >making?
>
> I begin with the empirical observation that existing MC programs can be very
> wrong in their estimation of the likely score of given positions, and
> therefore
> of the winning probabilities of the various moves. Consider a group which
> dies
> due to a skillful placement. If I know about this irrefutable move, I
> estimate that
> your group is dead, and the score is 20 points in my favor. If I do not know
> that
> move, my estimate might be that the game is yours by half a point.
>
> Now, in a universe of equally blind bots, a poor estimate can be better than
> a
> slightly worse estimate; but to compete against pro human players, one must
> be
> able to get fairly close to the correct score for stable positions.
>
> My point is that there appears to be a systemic error in the existing
> estimation process.
> Relating back to the move generation used by "random" playouts; amongst
> skilled
> players, it is quite common to consider ways to reduce groups to the
> single-eyed state.
> ( The Cotsen Go Tournament sweatshirts read "Cyclops Assassin" for this
> reason. )
>
> Under fast time controls, humans may fail to notice some nakade
> opportunities. It is
> also possible to exploit nakade, but to have a bot continue playing as if it
> were still in
> the game, eventually winning on time. When human players discover that it is
> important
> to explicitly kill such groups, the winning rates of such bots will plummet.
>
> I suggest that a useful stage in the evolution of "heavy playouts" might be
> to incorporate
> provably-correct analysis of group status, placements, and "fighting spirit"
> heuristics. This would
> skew the distribution of playouts toward that actually used by skilled
> players, improving the accuracy
> of the estimation. As my friend and coach Chris H often says: "When in
> doubt, read it out."
>
>
>  
> Looking for last minute shopping deals? Find them fast with Yahoo! Search.
> ___
> 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: evaluating monte carlo results

[dhillismail]

My program is riddled with code to try and make use of this. (It's always 
bothered me that UCT relies on the standard deviation of (often) multi-modal 
distributions.) It hasn't made my engine any stronger but it has helped me 
understand some things better. 

-Original Message-
From: Dave Dyer <[EMAIL PROTECTED]>
To: computer-go 
Sent: Thu, 6 Dec 2007 3:13 pm
Subject: [computer-go] Re: evaluating monte carlo results



At 11:39 AM 12/6/2007, terry mcintyre wrote:
>Any estimate of winning probability is only as good as the estimates of 
>whether 
particular games are actually won or lost.

I propose that monte carlo programs should produce a distribution of
quantitative outcomes rather than just a simple %win.  It's
only a very little more information to collect if you bin
the outcomes in 10 point increments.  

Given this kind of data, you could prefer moves that had a narrower
distribution of outcomes, and positively avoid those with bimodal
distributions where 51% win big and 49% lose big.

.. or it might be found that the distribution of outcomes is
not a usable factor.

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



More new features than ever.  Check out the new AIM(R) Mail ! - 
http://o.aolcdn.com/cdn.webmail.aol.com/mailtour/aol/en-us/text.htm?ncid=aimcmp000501
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] low-hanging fruit - yose

[terry mcintyre]

From: Nick Wedd <[EMAIL PROTECTED]>

>>which will alter the score not by one point, but by ten or twenty. 
>>Their estimate of winning probability is totally wrong. Good players
>>winnow out losing moves and stick with good moves - the basic premise
>>of minimax searching. Losing a big group will lead to a win only if
 one
>>obtains equivalent compensation elsewhere. Good players sometimes make
>>sacrifice plays, but failing to recognize that one's group is lost
 will
>>totally skew one's estimate of one's winning chances.

>We all know that MC programs don't play perfectly.  What point are you 
>making?

I begin with the empirical observation that existing MC programs can be very
wrong in their estimation of the likely score of given positions, and therefore
of the winning probabilities of the various moves. Consider a group which dies 
due to a skillful placement. If I know about this irrefutable move, I estimate 
that 
your group is dead, and the score is 20 points in my favor. If I do not know 
that 
move, my estimate might be that the game is yours by half a point.

Now, in a universe of equally blind bots, a poor estimate can be better than a 
slightly worse estimate; but to compete against pro human players, one must be 
able to get fairly close to the correct score for stable positions.

My point is that there appears to be a systemic error in the existing 
estimation process.
Relating back to the move generation used by "random" playouts; amongst skilled
players, it is quite common to consider ways to reduce groups to the 
single-eyed state.
( The Cotsen Go Tournament sweatshirts read "Cyclops Assassin" for this reason. 
)

Under fast time controls, humans may fail to notice some nakade opportunities. 
It is
also possible to exploit nakade, but to have a bot continue playing as if it 
were still in
the game, eventually winning on time. When human players discover that it is 
important
to explicitly kill such groups, the winning rates of such bots will plummet.

I suggest that a useful stage in the evolution of "heavy playouts" might be to 
incorporate
provably-correct analysis of group status, placements, and "fighting spirit" 
heuristics. This would 
skew the distribution of playouts toward that actually used by skilled players, 
improving the accuracy 
of the estimation. As my friend and coach Chris H often says: "When in doubt, 
read it out."






  

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Where and How to Test the Strong Programs?

[Rémi Coulom]

Christoph Birk wrote:

On Tue, 4 Dec 2007, Christoph Birk wrote:

On Tue, 4 Dec 2007, Don Dailey wrote:

It would be awkward at best.   I could build a client to do this,  but
the human would have to be willing to sit and play games at the moment
they were scheduled.


You are right ... it's very awkward. I lost one game by typo
and another by time.


I added a simple GUI to my program to play on CGOS ...
but I am not doing very well :-(

Any (dan) volunteer(s) ?

Christoph
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
I noticed handtalk on CGOS. Does anybody knows if it is the Chinese 
program ? I thought it may be a human player, because it does not play 
so many games in a row, and appeared when we talked about gtpdisplay. If 
it is really the Chinese HandTalk program, then it is stronger than I 
would have expected of a classical program.


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

Re: [computer-go] Where and How to Test the Strong Programs?

[Christoph Birk]

On Tue, 4 Dec 2007, Christoph Birk wrote:

On Tue, 4 Dec 2007, Don Dailey wrote:

It would be awkward at best.   I could build a client to do this,  but
the human would have to be willing to sit and play games at the moment
they were scheduled.


You are right ... it's very awkward. I lost one game by typo
and another by time.


I added a simple GUI to my program to play on CGOS ...
but I am not doing very well :-(

Any (dan) volunteer(s) ?

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

Re: [computer-go] low-hanging fruit - yose

[Nick Wedd]

In message <[EMAIL PROTECTED]>, terry mcintyre 
<[EMAIL PROTECTED]> writes

Any estimate of winning probability is only as good as the estimates of
whether particular games are actually won or lost.

Evidently, even strong programs fail to recognize the impact of nakade,


MC programs don't even have any concept of nakade.  Nevertheless, the 
best of them are stronger than programs that do.



which will alter the score not by one point, but by ten or twenty. 
Their estimate of winning probability is totally wrong. Good players
winnow out losing moves and stick with good moves - the basic premise
of minimax searching. Losing a big group will lead to a win only if one
obtains equivalent compensation elsewhere. Good players sometimes make
sacrifice plays, but failing to recognize that one's group is lost will
totally skew one's estimate of one's winning chances.


We all know that MC programs don't play perfectly.  What point are you 
making?


Nick
--
Nick Wedd[EMAIL PROTECTED]
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: evaluating monte carlo results

[Dave Dyer]

At 11:39 AM 12/6/2007, terry mcintyre wrote:
>Any estimate of winning probability is only as good as the estimates of 
>whether particular games are actually won or lost.

I propose that monte carlo programs should produce a distribution of
quantitative outcomes rather than just a simple %win.  It's
only a very little more information to collect if you bin
the outcomes in 10 point increments.  

Given this kind of data, you could prefer moves that had a narrower
distribution of outcomes, and positively avoid those with bimodal
distributions where 51% win big and 49% lose big.

.. or it might be found that the distribution of outcomes is
not a usable factor.

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

Re: [computer-go] low-hanging fruit - yose

[Raymond Wold]

On Thu, 2007-12-06 at 14:21 -0500, Don Dailey wrote:

> > However, the estimated probability of winning may be way off. It is
> > well known that Mogo, and perhaps some other programs, fail to
> > recognize common nakade placements, which leads to fundamental
> > estimation errors. An algorithm with more of a "fighting spirit"
> > would defend against nakade, and attack enemy groups; perhaps making
> > up for the loss of one group by the capture of another.
> > 
> > Any algorithm which drives the win toward 0.5 is always going to be
> > brittle; 
> It doesn't "drive" the win towards 0.5.It doesn't view them as any
> differently.   However, they will  prefer a bigger win if there is any
> room for error.Usually a bigger win is a more likely win - it's
> only in the cases where it isn't that Monte Carlo program do not care.
> 
> This is a fundamental error in how people think about this. Your
> intuition is that you should try for a bigger win just in case - or
> that it improves your overall winning chances.But if 10,000 monte
> carlo playouts see one line as winning 10,000 times and another line
> as winning 9,999 times,  even if most of those wins are BIG,   it will
> choose the sure thing.   

And maybe that cause them to lose more games. I understand the appeal of
an elegant solution, but until we have such computing power that MC is
practically identical to a complete game search, they will sometimes
miss things, things that lose them a lot of points, or things that lose
them some points. The latter doesn't matter if it has a significant lead
that it hasn't thrown away.

> Another way to look at it is this:   If there are 2 key groups being
> fought over, and winning either one wins the game,  it will choose the
> group that it is MOST likely to win - even if it is far smaller.   
> 
> There really is no way to improve on this except to trick it into NOT
> maximizing it's winning probability. You might end up with a
> program that appears to play more human,  but it will sacrifice some
> playing strength.   

Why would it lose playing strength by hedging its bets on making
mistakes?

Right now, if it plays under the assumption that it makes no mistakes
(0.5 margin is enough to win the game), then some percentage X of the
games will be lost because it misses things. If it plays under the
assumption that it might make mistakes worth Y points (thus play as if a
Y+0.5 point margin is needed to win the game), then it will in some
percentage of games Z lose because it played too risky, took chances it
didn't have to.

If Xhttp://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] low-hanging fruit - yose

[terry mcintyre]

Any estimate of winning probability is only as good as the estimates of whether 
particular games are actually won or lost.

Evidently, even strong programs fail to recognize the impact of nakade, which 
will alter the score not by one point, but by ten or twenty.  Their estimate of 
winning probability is totally wrong. Good players winnow out losing moves and 
stick with good moves - the basic premise of minimax searching. Losing a big 
group will lead to a win only if one obtains equivalent compensation elsewhere. 
Good players sometimes make sacrifice plays, but failing to recognize that 
one's group is lost will totally skew one's estimate of one's winning chances. 





  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] low-hanging fruit - yose

[terry mcintyre]

From: terry mcintyre <[EMAIL PROTECTED]>

For a large number of playouts, the estimated scores should converge as the 
game progresses. This is particularly true if the random distributions strongly 
favor moves where each opponent  monotonically increases the score - keeping 
one's groups alive, keeping the opponent dead, and growing areas wherever 
possible. Of course there must be enough variability to permit sacrifice plays 
and nakade placements; throwing a stone into a group will initially look like a 
bad play, but if the placement succeeds, it is a very good play, the success of 
which must be properly attributed to the
 earlier placement - or even further back, to the surrounding and cutting and 
eye-killing moves which ultimately led to the placement move.



--- expanding my own email:

Is it possible to cache the results of life-and-death analysis for use by 
playouts, so that dead groups stay dead, live groups stay alive, areas 
increase, and players tend to efficiently improve the status of their own 
groups ( and demote the status of the opponents' ) wherever that is feasible?






  

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Elo and handicap matching

[Lavergne Thomas]

I suggest to make the bots play on kgs but on 9x9 versus human, so we
could known approximatively the level of theses bots against human.
We can also know the relative strenght of these bots against other bots
on cgos in the same conditions (i.e. board size, timing, rules...) so we
could estimate the level of all the bots against human.
I don't want to mix 19x19 and 9x9.

This is far from perfect because human ranks was not fixed on 9x9 but on
19x19, but I think for humans ranks on both size are corelated. As
preivously said by me and others humans ranks on 9x9 are not fully
corelated on 9x9 and 19x19, I known some people whom I can give 4 or 5
stones on 19x19 but beat me on 9x9 on even games because they practised
a lot more than me at this size, but on kgs theses ranks are roughly
corelated.

Tom

On Thu, Dec 06, 2007 at 02:05:39PM -0500, Don Dailey wrote:
> 
> 
> Lavergne Thomas wrote:
> > If some bot can be setup to play on kgs for enough time to get a solid
> > rank and then put on cgos to get an elo rating with the same
> > configuration we could find a formula to convert elo to kgs ranks.
> > For sure, this is not perfect but I think is good enought.
> >   
> Here are the issues.   You want to know how good a 19x19 HUMAN 1 dan
> player would do on CGOS  playing 9x9.This is because there is no
> real ranking system for 9x9 and yet you would like to be able to say
> that program xyz plays 2 dan strength,  even though the ranking system
> wasn't really designed for 9x9 Go.   We just need a "point of
> reference" so that we can say in general terms that a program like Mogo
> on CGOS is playing 2 dan strength (or whatever it really is.)  
> 
> But most of us feel that you cannot do this with GO programs - you need
> humans.   For instance you could take GnuGo,  get a 19x19 rating and
> then play on 9x9 CGOS and use it as a reference point.However GnuGo
> was not designed to play 9x9 go.   My own program Lazarus is terrible at
> 19x19 but pretty good at 9x9.   It could probably give a low kyu player
> a really good game on 9x9 but it would be easily beat at 19x19 - so it's
> not a good way to standardize.I believe GnuGo is more balanced in
> this way - but it's probably a bad idea in general to figure it this way.
> 
> Your idea is fine for 19x19 CGOS.  
> 
> - Don
> 
> 
> 
> > Tom
> >
> > On Tue, Dec 04, 2007 at 05:30:15PM -0500, Don Dailey wrote:
> >   
> >> The only issue is that I don't know if GnuGo is representative of 19x19
> >> to 9x9 go strength.   I am interested in knowing how a human 19x19
> >> scales down to 9x9 play.  It's well known that programs scale up 
> >> poorly.
> >>
> >> However, this data should still be quite useful.
> >>
> >> - Don
> >>
> >> 
> >
> >   
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/

-- 
Thomas Lavergne"Entia non sunt multiplicanda praeter
 necessitatem." (Guillaume d'Ockham)
[EMAIL PROTECTED]http://oniros.org
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] low-hanging fruit - yose

[Don Dailey]

terry mcintyre wrote:
> I understand that Monte Carlo algorthms are driven by the "winning
> probability", and a 0.5 win looks as good - or maybe even better -
> than a 100-point win.
>
It doesn't view 0.5 as "better"



> However, the estimated probability of winning may be way off. It is
> well known that Mogo, and perhaps some other programs, fail to
> recognize common nakade placements, which leads to fundamental
> estimation errors. An algorithm with more of a "fighting spirit" would
> defend against nakade, and attack enemy groups; perhaps making up for
> the loss of one group by the capture of another.
>
> Any algorithm which drives the win toward 0.5 is always going to be
> brittle;
It doesn't "drive" the win towards 0.5.It doesn't view them as any
differently.   However, they will  prefer a bigger win if there is any
room for error.Usually a bigger win is a more likely win - it's only
in the cases where it isn't that Monte Carlo program do not care.

This is a fundamental error in how people think about this. Your
intuition is that you should try for a bigger win just in case - or that
it improves your overall winning chances.But if 10,000 monte carlo
playouts see one line as winning 10,000 times and another line as
winning 9,999 times,  even if most of those wins are BIG,   it will
choose the sure thing.  

Another way to look at it is this:   If there are 2 key groups being
fought over, and winning either one wins the game,  it will choose the
group that it is MOST likely to win - even if it is far smaller.  

There really is no way to improve on this except to trick it into NOT
maximizing it's winning probability. You might end up with a program
that appears to play more human,  but it will sacrifice some playing
strength.  

It might be possible to make it "break ties" when all else is equal and
get more natural play without sacrificing playing strength.

You say:  When monte carlo program lose, they lose big.  Yes, that tends
to be true.  They essentially give up in dead lost positions (even
though it may not be obvious to us.)  But they NEVER gradually drift
into a losing position because they play passively when they should be
fighting.   If they should be fighting they will fight and play very
purposefully.  


> any problems with the accuracy of the evaluation may place one on the
> losing side of that 0.5 divide. Hence, if it is possible to be more
> greedy - to seal off groups, to play for every yose point, to fill in
> dame first - programs based on monte carlo will improve.
No they won't.If you can do this in such as way that the maximizing
behavior is not sacrificed, it's possible that they will salvage some
lost games.But these will be DEAD LOST games they salvage,  not
games where there is some hope (by their estimation) - because if there
is some hope this very behavior you are criticizing them for will cause
them to focus very heavily on ANY move that gives them a fighting chance
- which won't be a silly non-move.  

> It's terrible to lose a won game by drifting over the edge of a
> precipice. When monte carlo programs lose, they lose big -- in my
> so-far limited observations, incorrect evaluation of life-and-death
> status leads to estimation errors which far exceed the 0.5 margin of
> error.
>
> For a large number of playouts, the estimated scores should converge
> as the game progresses. This is particularly true if the random
> distributions strongly favor moves where each opponent  monotonically
> increases the score - keeping one's groups alive, keeping the opponent
> dead, and growing areas wherever possible. Of course there must be
> enough variability to permit sacrifice plays and nakade placements;
> throwing a stone into a group will initially look like a bad play, but
> if the placement succeeds, it is a very good play, the success of
> which must be properly attributed to the earlier placement - or even
> further back, to the surrounding and cutting and eye-killing moves
> which ultimately led to the placement move.
>
> Terry McIntyre <[EMAIL PROTECTED]>
> They mean to govern well; but they mean to govern. They promise to be
> kind masters; but they mean to be masters. -- Daniel Webster
>
>
> 
> Never miss a thing. Make Yahoo your homepage.
> 
> 
>
> ___
> 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] Elo and handicap matching

[Don Dailey]

Lavergne Thomas wrote:
> If some bot can be setup to play on kgs for enough time to get a solid
> rank and then put on cgos to get an elo rating with the same
> configuration we could find a formula to convert elo to kgs ranks.
> For sure, this is not perfect but I think is good enought.
>   
Here are the issues.   You want to know how good a 19x19 HUMAN 1 dan
player would do on CGOS  playing 9x9.This is because there is no
real ranking system for 9x9 and yet you would like to be able to say
that program xyz plays 2 dan strength,  even though the ranking system
wasn't really designed for 9x9 Go.   We just need a "point of
reference" so that we can say in general terms that a program like Mogo
on CGOS is playing 2 dan strength (or whatever it really is.)  

But most of us feel that you cannot do this with GO programs - you need
humans.   For instance you could take GnuGo,  get a 19x19 rating and
then play on 9x9 CGOS and use it as a reference point.However GnuGo
was not designed to play 9x9 go.   My own program Lazarus is terrible at
19x19 but pretty good at 9x9.   It could probably give a low kyu player
a really good game on 9x9 but it would be easily beat at 19x19 - so it's
not a good way to standardize.I believe GnuGo is more balanced in
this way - but it's probably a bad idea in general to figure it this way.

Your idea is fine for 19x19 CGOS.  

- Don



> Tom
>
> On Tue, Dec 04, 2007 at 05:30:15PM -0500, Don Dailey wrote:
>   
>> The only issue is that I don't know if GnuGo is representative of 19x19
>> to 9x9 go strength.   I am interested in knowing how a human 19x19
>> scales down to 9x9 play.  It's well known that programs scale up poorly.
>>
>> However, this data should still be quite useful.
>>
>> - Don
>>
>> 
>
>   
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] cgos

[Harri Salakoski]

All right thanks, so whos turn it is don't matter, it is part of my hashcode 
implementation.
I completely forget that fact and only looked position and think only that 
black has not got that position before. But thats easy to fix thanks.


t. harri

- Original Message - 
From: "Nick Wedd" <[EMAIL PROTECTED]>

To: "computer-go" 
Sent: Thursday, December 06, 2007 3:19 PM
Subject: Re: [computer-go] cgos


In message <[EMAIL PROTECTED]>, Harri Salakoski 
<[EMAIL PROTECTED]> writes

Hi is last black move A4 really illegal in cgos rules?
Just ensure before start change things. It seemed weird.
White D9 shouls change board situation and white kills two stones before 
A4 is getting then

one stone back fine? t. harri

W A4
9 WW..W.WWW
8 ...W.W.W.
7 WBW..
6 WBBWBBWWW
5 .WWWB
4 BWBBB
3 .BBB.B.B.
2 B.B.B
1 .
ABCDEFGHJ

W D9
9 WW.WW.WWW
8 ...W.W.W.
7 WBW..
6 WBBWBBWWW
5 .WWWB
4 BWBBB
3 .BBB.B.B.
2 B.B.B
1 .
ABCDEFGHJ

B A5
9 WW.WW.WWW
8 ...W.W.W.
7 WBW..
6 WBBWBBWWW
5 BWWWB
4 BWBBB
3 .BBB.B.B.
2 B.B.B
1 .
ABCDEFGHJ

W A3
9 WW.WW.WWW
8 ...W.W.W.
7 WBW..
6 WBBWBBWWW
5 .WWWB
4 .WBBB
3 WBBB.B.B.
2 B.B.B
1 .
ABCDEFGHJ

B A4
9 WW.WW.WWW
8 ...W.W.W.
7 WBW..
6 WBBWBBWWW
5 .WWWB
4 BWBBB
3 .BBB.B.B.
2 B.B.B
1 .
ABCDEFGHJ


Here are the positions, edited to make them more legible:

W A4  [in fact it is B who has just played A4]

 O O . . O . O O O
 . . . O . O . O .
 O # O . O O O O .
 O # # O # # O O O
 . O O O # # # # #
 # O # # # # # # #
 . # # # . # . # .
 # . # # # # # . #
 # # # # # # # # .


W  D9  [Note this position, I will refer to it later]

 O O . O O . O O O
 . . . O . O . O .
 O # O . O O O O .
 O # # O # # O O O
 . O O O # # # # #
 # O # # # # # # #
 . # # # . # . # .
 # . # # # # # . #
 # # # # # # # # .


B  A5

 O O . O O . O O O
 . . . O . O . O .
 O # O . O O O O .
 O # # O # # O O O
 # O O O # # # # #
 # O # # # # # # #
 . # # # . # . # .
 # . # # # # # . #
 # # # # # # # # .


W  A3

 O O . O O . O O O
 . . . O . O . O .
 O # O . O O O O .
 O # # O # # O O O
 . O O O # # # # #
 . O # # # # # # #
 O # # # . # . # .
 # . # # # # # . #
 # # # # # # # # .


 B A4

 O O . O O . O O O
 . . . O . O . O .
 O # O . O O O O .
 O # # O # # O O O
 . O O O # # # # #
 # O # # # # # # #
 . # # # . # . # .
 # . # # # # # . #
 # # # # # # # # .


If "positional superko" is in force, this last move is illegal, as it 
recreates the position noted previously.


Nick
--
Nick Wedd[EMAIL PROTECTED]
___
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] low-hanging fruit - yose

[terry mcintyre]

I understand that Monte Carlo algorthms are driven by the "winning 
probability", and a 0.5 win looks as good - or maybe even better - than a 
100-point win.

However, the estimated probability of winning may be way off. It is well known 
that Mogo, and perhaps some other programs, fail to recognize common nakade 
placements, which leads to fundamental estimation errors. An algorithm with 
more of a "fighting spirit" would defend against nakade, and attack enemy 
groups; perhaps making up for the loss of one group by the capture of another.

Any algorithm which drives the win toward 0.5 is always going to be brittle; 
any problems with the accuracy of the evaluation may place one on the losing 
side of that 0.5 divide. Hence, if it is possible to be more greedy - to seal 
off groups, to play for every yose point, to fill in dame first - programs 
based on monte carlo will improve. It's terrible to lose a won game by drifting 
over the edge of a precipice. When monte carlo programs lose, they lose big -- 
in my so-far limited observations, incorrect evaluation of life-and-death 
status leads to estimation errors which far exceed the 0.5 margin of error.

For a large number of playouts, the estimated scores should converge as the 
game progresses. This is particularly true if the random distributions strongly 
favor moves where each opponent  monotonically increases the score - keeping 
one's groups alive, keeping the opponent dead, and growing areas wherever 
possible. Of course there must be enough variability to permit sacrifice plays 
and nakade placements; throwing a stone into a group will initially look like a 
bad play, but if the placement succeeds, it is a very good play, the success of 
which must be properly attributed to the earlier placement - or even further 
back, to the surrounding and cutting and eye-killing moves which ultimately led 
to the placement move.

Terry McIntyre <[EMAIL PROTECTED]>

They mean to govern well; but they mean to govern. They promise to be kind 
masters; but they mean to be masters. -- Daniel Webster




  

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

RE: [computer-go] Re: Update of MoGo binary release, and windows version available! (repost)

[Moi de Quoi]

On Thu, 2007-12-06 at 15:07 +0100, Edward de Grijs wrote:
> 

>  
> To check things even more, I tried to communicate using C with
> popen():
> > FILE *ptr;
> > if ((ptr = popen("mogo --9 --nbTotalSimulations 3000 > mogoout",
> "w")) != NULL)
> > {
> > fprintf(ptr, "boardsize 9\n");
> > fprintf(ptr, "genmove b\n");
> > sleep(60);
> > }
>  
> But the result is the same, after these commands, mogo still continues
> to
> perform multiple genmoves. I am puzzled here...
>  
> I will look at the ruby script, and there are also twogtp scripts of
> gnugo
> in python, perl etc. which I could check.

If the output is through a pipe, it is probably 'block-buffered'.
Try throwing in a few fflush()es, or set the buffering with setvbuf()
et.al.

man setvbuf

HTH,
AvK

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

Re: [computer-go] New engine? From a Chess programmer perspective.

[Lavergne Thomas]

There is also the fact that some amateurs plays a lot of 9x9 game and
get a better feeling about it, so when they meet a stronger opponent but
who don't have played a lot of game on 9x9 they can crush it.

Tom

On Tue, Dec 04, 2007 at 11:32:45AM +, Jacques Basaldúa wrote:
> Christoph Birk wrote:
>
>> I don't think 2200 ELO on the 9x9 CGOS is equivalent to 'high dan-level' 
>> play.
>
> Neither do I. In fact the whole kyu/dan rating system applies
> only to 19x19. 9x9 is not deep enough to have have so many ranks.
> On a 9x9 board an average amateur beats a pro with handicap 3.
> That amateur would be crushed by the pro with handicap 9 in 19x19.
>
> Jacques.
>
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/

-- 
Thomas Lavergne"Entia non sunt multiplicanda praeter
 necessitatem." (Guillaume d'Ockham)
[EMAIL PROTECTED]http://oniros.org
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Elo and handicap matching

[Lavergne Thomas]

If some bot can be setup to play on kgs for enough time to get a solid
rank and then put on cgos to get an elo rating with the same
configuration we could find a formula to convert elo to kgs ranks.
For sure, this is not perfect but I think is good enought.

Tom

On Tue, Dec 04, 2007 at 05:30:15PM -0500, Don Dailey wrote:
> The only issue is that I don't know if GnuGo is representative of 19x19
> to 9x9 go strength.   I am interested in knowing how a human 19x19
> scales down to 9x9 play.  It's well known that programs scale up poorly.
> 
> However, this data should still be quite useful.
> 
> - Don
> 

-- 
Thomas Lavergne"Entia non sunt multiplicanda praeter
 necessitatem." (Guillaume d'Ockham)
[EMAIL PROTECTED]http://oniros.org
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] low-hanging fruit

[terry mcintyre]

I'll dig into the scoring algorithms used by GoGui; my guess is that it counted 
handicap stones differently than Mogo.

Regarding nakade: I had a friend with a shodan ranking play a 9x9 game, no 
handicap, against Mogo, which Mogo lost due to a nakade in the corner. Mogo 
apparently believed it had a live group, and all of its moves were based on the 
assumption that it was therefore ahead by at least 0.5 points. As soon as we 
filled in the liberties and explicitly killed the group, Mogo resigned. I, an 
AGA 8 kyu, spotted the nakade with ease; it was a bulky five arrangement;  when 
the vital point is played, only one eye can be made.

I don't know how hard it is to fix this bug, but if Mogo can avoid nakade, it 
will surely win many more games. 

Terry McIntyre <[EMAIL PROTECTED]>
They mean to govern well; but they mean to govern. They promise to be kind 
masters; but they mean to be masters. -- Daniel Webster




  

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: The global search myth

[Dave Dyer]

>As any incomplete search, it can blunder, but why more than any other 
>incomplete search?

Not worse, just not a magic bullet.


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

Re[2]: [computer-go] ELO Ratings of move pattern

[Lars Schäfers]

Yes! You are write. I haven't mentioned this. It's a good idea to swap
them all in the form that black has the move-right. Thank you!

I'll fix that. But not today ;)

If you find any inconsistencies in the data please let me know!

By the way: I forgot to cut the file at the end. You should only use
the values of pattern with an ID < 0x4.

ÁB> Thanks for the file! This should be very helpful when I try to reproduce 
results.

ÁB> It looks like you are not taking advantage of symmetries. For instance,
ÁB> 88|0|17.033168
ÁB> 88|1|12.263955

ÁB> and
ÁB> 164|0|17.388714
ÁB> 164|1|25.862695

ÁB> Are identical except for swapping the roles of white and
ÁB> black (88 == 1120 in base 4, 164 == 2210 in base 4), and therefore
ÁB> they should have the same scores. If you do take symmetries of
ÁB> this type into consideration, you #39;ll reduce the number of
ÁB> gamma values you have to compute by a factor of almost 16 (8
ÁB> symmetries in the D4 group, times 2 colors). This should result in
ÁB> faster learning and better estimates.

ÁB> Álvaro.


ÁB> On Dec 6, 2007 4:28 AM, Lars <[EMAIL PROTECTED]> wrote:
ÁB> While you can find the gamma-values of non-shape patterns in the paper
ÁB> of Remi, I can give you the list of shape-pattern gamma-values.

ÁB> The source-code is mixed with my engine-code, which i don #39;t like to
ÁB> publish. But the algorithm is more or less easy to implement..

ÁB> I #39;ll try to attach the file to this mail, if it don #39;t work I send 
it to
ÁB> your address.

ÁB> The file have the following coding:
ÁB> It #39;s a text-file with one pattern each line.
ÁB> Lines look as:
ÁB> Pattern-ID|Move-right(0=black, 1=white)|gamma-value\n

ÁB> The Pattern-IDs have the following coding:
ÁB> In the binary representation of the ID you have 2 Bits for every field.
ÁB> So you have 18 Bits at all.
ÁB> 00 = Empty, 01 = Black, 02 = White, 03 = Edge
ÁB> The pairs are ordered as:
ÁB> 1 2 3
ÁB> 4 5 6
ÁB> 7 8 9
ÁB> in the ID it is
ÁB> 123456789

ÁB> While you can rotate and mirror the patterns only one respresentation of
ÁB> the various possible representations is contained in the file.

>>
>> On Dec 5, 2007 3:17 PM, Lars <[EMAIL PROTECTED]> wrote:
>>         Thank you for your explanations!
>>         You were right, it was a bug, and now it works really fine.
>>
>> Are you (or Remi) willing to publish any of the following?
>> 1. Source code for extracting ELO ratings for moves
>> 2. Full list of gamma values, including patterns
>>
>>
>> Either of those would help kick start those of us that are just
>> starting to go down a similar road.
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/

ÁB> ___
ÁB> computer-go mailing list
ÁB> computer-go@computer-go.org
ÁB> 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] ELO Ratings of move pattern

[Rémi Coulom]

Jason House wrote:


This may serve as a good test of if there is enough data to assign 
values to the patterns.


I did not mention this in my paper, but you can rather easily estimate 
uncertainty margins around Elo values. This involves computing the 
second-order derivative of the probability distribution with respect to 
log(gamma). Since the distribution has a shape that looks very much like 
a Gaussian, the second-order derivative at the maximum is a good 
estimation of -1/sigma². That is how I compute confidence intervals in 
bayeselo.


Also, in the conclusion of my paper, I suggest that it may be better to 
avoid using consecutive positions in the same game as learning data, 
because they are not independent, and the whole learning process assumes 
independence. Some quick experiments I made tend to indicate that this 
is important. Using 3 times more games, and keeping only one position 
out of 3 improved learning. I did not investigate this very deeply, so I 
cannot give more precise data, but keep in mind that it is dangerous to 
use consecutive positions because their are too similar, and may lead to 
over-estimation of the confidence in pattern evaluation.


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

Re: [computer-go] ELO Ratings of move pattern

[Jason House]

On Dec 6, 2007 10:13 AM, Álvaro Begué <[EMAIL PROTECTED]> wrote:

>
>
> On Dec 6, 2007 10:06 AM, Jason House <[EMAIL PROTECTED]> wrote:
>
> >
> >
> > On Dec 6, 2007 7:13 AM, Álvaro Begué <[EMAIL PROTECTED]> wrote:
> >
> > > 88|0|17.033168
> > > 88|1|12.263955
> > >
> > > and
> > >
> > > 164|0|17.388714
> > > 164|1|25.862695
> > >
> > > Are identical except for swapping the roles of white and black
> >
> >
> > Curiously, the gamma values in your example are way different
> >
> > 17.033168 vs 25.862595
> > and
> > 12.263955 vs 17.388714
> >
>
> That was exactly my point. Those should theoretically be identical, which
> means that the difference comes purely from noise. The games that were used
> for training probably don't have enough examples of these patterns to get a
> good estimate of their true strength.
>

This may serve as a good test of if there is enough data to assign values to
the patterns.



Actually, the gamma values are only determined up to a multiplication of all
> of them by a constant. Because patterns with white to move and patterns with
> black to move never compete with each other, they may have drifted in such a
> way that the discrepancy is not as large as it seems (since both ratios
> 25.862595/17.033168 and 17.388714/12.263955 are similar).
>

That may be a fluke.  Other pairs have a much different ratio
0|0|1.463386
0|1|1.337276



> Still, forcing those gamma values to be identical seems like the right
> thing to do.
>

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

Re: [computer-go] ELO Ratings of move pattern

[Álvaro Begué]

On Dec 6, 2007 10:06 AM, Jason House <[EMAIL PROTECTED]> wrote:

>
>
> On Dec 6, 2007 7:13 AM, Álvaro Begué <[EMAIL PROTECTED]> wrote:
>
> > 88|0|17.033168
> > 88|1|12.263955
> >
> > and
> >
> > 164|0|17.388714
> > 164|1|25.862695
> >
> > Are identical except for swapping the roles of white and black
>
>
> Curiously, the gamma values in your example are way different
>
> 17.033168 vs 25.862595
> and
> 12.263955 vs 17.388714
>

That was exactly my point. Those should theoretically be identical, which
means that the difference comes purely from noise. The games that were used
for training probably don't have enough examples of these patterns to get a
good estimate of their true strength.

Actually, the gamma values are only determined up to a multiplication of all
of them by a constant. Because patterns with white to move and patterns with
black to move never compete with each other, they may have drifted in such a
way that the discrepancy is not as large as it seems (since both ratios
25.862595/17.033168 and 17.388714/12.263955 are similar).

Still, forcing those gamma values to be identical seems like the right thing
to do.

Álvaro.



>
>
> ___
> 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] ELO Ratings of move pattern

[Jason House]

On Dec 6, 2007 7:13 AM, Álvaro Begué <[EMAIL PROTECTED]> wrote:

> 88|0|17.033168
> 88|1|12.263955
>
> and
>
> 164|0|17.388714
> 164|1|25.862695
>
> Are identical except for swapping the roles of white and black


Curiously, the gamma values in your example are way different

17.033168 vs 25.862595
and
12.263955 vs 17.388714
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: Update of MoGo binary release, and windows version available! (repost)

[Hideki Kato]

Edward de Grijs: <[EMAIL PROTECTED]>:
>
>
>Thanks Hideki, Chris and Jacques for your replies.
> 
>> Hideki wrote:
>> Then, you can make a very simple program that passes a file to stdout
>> first and passes stdin to stdout after the end-of-file of the file.
>> And use it as "a.out file | mogo ".
>Is this not the way a "tail -f" works?

I don't know the way "tail -f" works but I guess _no_ as "tail" never 
use stdin.  That is, the program opens the file at first and copy it 
to stdout unitl end-of-file.  Then the program closes the file and 
opens stdin and copy it to stdout.

>This is the method I use with gnugo to let te programs play against
>each other. The communication between the programs and server program
>are all using files. This seems fast enough, while I can check all
>the communications which took place.
>This tail -f fails in the same way.
> 
>To check things even more, I tried to communicate using C with popen():
>> FILE *ptr;
>> if ((ptr = popen("mogo --9 --nbTotalSimulations 3000 > mogoout", "w")) != 
>> NULL)
>> {
>> fprintf(ptr, "boardsize 9\n");
>> fprintf(ptr, "genmove b\n");
>> sleep(60);
>> }
> 
>But the result is the same, after these commands, mogo still continues to
>perform multiple genmoves. I am puzzled here...

I guess above code does not work.  Probably MoGo reads the last line 
repeatedly when end-of-file occurs.

Hideki

>I will look at the ruby script, and there are also twogtp scripts of gnugo
>in python, perl etc. which I could check.
> 
>Edward.
> 
> 
> 
>_
>Probeer Live.nl 
>Probeer Live.nl: zoekmachine van de makers van MSN! 
> inline file
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] ELO Ratings of move pattern

[Chris Fant]

Oh, I didn't notice at first that the player-to-move was encoded
seperatly from the pattern shape.

On Dec 6, 2007 9:53 AM, Álvaro Begué <[EMAIL PROTECTED]> wrote:
>
>
>
> On Dec 6, 2007 9:31 AM, Chris Fant <[EMAIL PROTECTED]> wrote:
> > But then you lose information on player-to-move, right?
>
> No. What I am saying is that it is as urgent for black to play on
>
> . . .
> . . X
> X O .
>
> as it is for white to play in
>
> . . .
> . . O
> O X .
>
> Precisely one way of implementing what I said is by only storing patterns
> with black to move. If it is white's turn, make turn the 01s into 10s and
> the 10s into 01s in the pattern and then do the lookup.
>
> Some code like this would do:
>
> unsigned switch_players_in_pattern(unsigned x){
>   return ((x&0x2)>>1) | ((x&0x1)<<1);
> }
>
> Álvaro.
>
>
> >
> >
> >
> >
> >
> >
> >
> >
> > On Dec 6, 2007 7:18 AM, Álvaro Begué <[EMAIL PROTECTED]> wrote:
> > > Oh, I see you have applied the symmetries, but not the swapping of
> roles.
> > > Still, this should probably be done and cut the number of gamma values
> in
> > > half.
> > >
> > > Álvaro.
> > >
> > >
> > >
> > >
> > > On Dec 6, 2007 7:13 AM, Álvaro Begué < [EMAIL PROTECTED]> wrote:
> > > > Thanks for the file! This should be very helpful when I try to
> reproduce
> > > results.
> > > >
> > > > It looks like you are not taking advantage of symmetries. For
> instance,
> > > > 88|0|17.033168
> > > > 88|1|12.263955
> > > > and
> > > > 164|0|17.388714
> > > >
> > > > 164|1|25.862695
> > > > Are identical except for swapping the roles of white and black (88 ==
> 1120
> > > in base 4, 164 == 2210 in base 4), and therefore they should have the
> same
> > > scores. If you do take symmetries of this type into consideration,
> you'll
> > > reduce the number of gamma values you have to compute by a factor of
> almost
> > > 16 (8 symmetries in the D4 group, times 2 colors). This should result in
> > > faster learning and better estimates.
> > > >
> > > > Álvaro.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Dec 6, 2007 4:28 AM, Lars <[EMAIL PROTECTED] > wrote:
> > > >
> > > > > While you can find the gamma-values of non-shape patterns in the
> paper
> > > > > of Remi, I can give you the list of shape-pattern gamma-values.
> > > > >
> > > > > The source-code is mixed with my engine-code, which i don't like to
> > > > > publish. But the algorithm is more or less easy to implement..
> > > > >
> > > > > I'll try to attach the file to this mail, if it don't work I send it
> to
> > > > > your address.
> > > > >
> > > > > The file have the following coding:
> > > > > It's a text-file with one pattern each line.
> > > > > Lines look as:
> > > > > Pattern-ID|Move-right(0=black, 1=white)|gamma-value\n
> > > > >
> > > > > The Pattern-IDs have the following coding:
> > > > > In the binary representation of the ID you have 2 Bits for every
> field.
> > > > > So you have 18 Bits at all.
> > > > > 00 = Empty, 01 = Black, 02 = White, 03 = Edge
> > > > > The pairs are ordered as:
> > > > > 1 2 3
> > > > > 4 5 6
> > > > > 7 8 9
> > > > > in the ID it is
> > > > > 123456789
> > > > >
> > > > > While you can rotate and mirror the patterns only one
> respresentation of
> > > > > the various possible representations is contained in the file.
> > > > >
> > > > > >
> > > > > > On Dec 5, 2007 3:17 PM, Lars <[EMAIL PROTECTED] > wrote:
> > > > > > Thank you for your explanations!
> > > > > > You were right, it was a bug, and now it works really
> fine.
> > > > > >
> > > > > > Are you (or Remi) willing to publish any of the following?
> > > > > > 1. Source code for extracting ELO ratings for moves
> > > > > > 2. Full list of gamma values, including patterns
> > > > > >
> > > > > >
> > > > > > Either of those would help kick start those of us that are just
> > > > > > starting to go down a similar road.
> > > > > > ___
> > > > > > 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 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/l

Re: [computer-go] ELO Ratings of move pattern

[Álvaro Begué]

On Dec 6, 2007 9:31 AM, Chris Fant <[EMAIL PROTECTED]> wrote:

> But then you lose information on player-to-move, right?


No. What I am saying is that it is as urgent for black to play on

. . .
. . X
X O .

as it is for white to play in

. . .
. . O
O X .

Precisely one way of implementing what I said is by only storing patterns
with black to move. If it is white's turn, make turn the 01s into 10s and
the 10s into 01s in the pattern and then do the lookup.

Some code like this would do:

unsigned switch_players_in_pattern(unsigned x){
  return ((x&0x2)>>1) | ((x&0x1)<<1);
}

Álvaro.



>
>
> On Dec 6, 2007 7:18 AM, Álvaro Begué <[EMAIL PROTECTED]> wrote:
> > Oh, I see you have applied the symmetries, but not the swapping of
> roles.
> > Still, this should probably be done and cut the number of gamma values
> in
> > half.
> >
> > Álvaro.
> >
> >
> >
> >
> > On Dec 6, 2007 7:13 AM, Álvaro Begué < [EMAIL PROTECTED]> wrote:
> > > Thanks for the file! This should be very helpful when I try to
> reproduce
> > results.
> > >
> > > It looks like you are not taking advantage of symmetries. For
> instance,
> > > 88|0|17.033168
> > > 88|1|12.263955
> > > and
> > > 164|0|17.388714
> > >
> > > 164|1|25.862695
> > > Are identical except for swapping the roles of white and black (88 ==
> 1120
> > in base 4, 164 == 2210 in base 4), and therefore they should have the
> same
> > scores. If you do take symmetries of this type into consideration,
> you'll
> > reduce the number of gamma values you have to compute by a factor of
> almost
> > 16 (8 symmetries in the D4 group, times 2 colors). This should result in
> > faster learning and better estimates.
> > >
> > > Álvaro.
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Dec 6, 2007 4:28 AM, Lars <[EMAIL PROTECTED] > wrote:
> > >
> > > > While you can find the gamma-values of non-shape patterns in the
> paper
> > > > of Remi, I can give you the list of shape-pattern gamma-values.
> > > >
> > > > The source-code is mixed with my engine-code, which i don't like to
> > > > publish. But the algorithm is more or less easy to implement..
> > > >
> > > > I'll try to attach the file to this mail, if it don't work I send it
> to
> > > > your address.
> > > >
> > > > The file have the following coding:
> > > > It's a text-file with one pattern each line.
> > > > Lines look as:
> > > > Pattern-ID|Move-right(0=black, 1=white)|gamma-value\n
> > > >
> > > > The Pattern-IDs have the following coding:
> > > > In the binary representation of the ID you have 2 Bits for every
> field.
> > > > So you have 18 Bits at all.
> > > > 00 = Empty, 01 = Black, 02 = White, 03 = Edge
> > > > The pairs are ordered as:
> > > > 1 2 3
> > > > 4 5 6
> > > > 7 8 9
> > > > in the ID it is
> > > > 123456789
> > > >
> > > > While you can rotate and mirror the patterns only one
> respresentation of
> > > > the various possible representations is contained in the file.
> > > >
> > > > >
> > > > > On Dec 5, 2007 3:17 PM, Lars <[EMAIL PROTECTED]> wrote:
> > > > > Thank you for your explanations!
> > > > > You were right, it was a bug, and now it works really
> fine.
> > > > >
> > > > > Are you (or Remi) willing to publish any of the following?
> > > > > 1. Source code for extracting ELO ratings for moves
> > > > > 2. Full list of gamma values, including patterns
> > > > >
> > > > >
> > > > > Either of those would help kick start those of us that are just
> > > > > starting to go down a similar road.
> > > > > ___
> > > > > 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 mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] ELO Ratings of move pattern

[Chris Fant]

But then you lose information on player-to-move, right?

On Dec 6, 2007 7:18 AM, Álvaro Begué <[EMAIL PROTECTED]> wrote:
> Oh, I see you have applied the symmetries, but not the swapping of roles.
> Still, this should probably be done and cut the number of gamma values in
> half.
>
> Álvaro.
>
>
>
>
> On Dec 6, 2007 7:13 AM, Álvaro Begué < [EMAIL PROTECTED]> wrote:
> > Thanks for the file! This should be very helpful when I try to reproduce
> results.
> >
> > It looks like you are not taking advantage of symmetries. For instance,
> > 88|0|17.033168
> > 88|1|12.263955
> > and
> > 164|0|17.388714
> >
> > 164|1|25.862695
> > Are identical except for swapping the roles of white and black (88 == 1120
> in base 4, 164 == 2210 in base 4), and therefore they should have the same
> scores. If you do take symmetries of this type into consideration, you'll
> reduce the number of gamma values you have to compute by a factor of almost
> 16 (8 symmetries in the D4 group, times 2 colors). This should result in
> faster learning and better estimates.
> >
> > Álvaro.
> >
> >
> >
> >
> >
> >
> > On Dec 6, 2007 4:28 AM, Lars <[EMAIL PROTECTED] > wrote:
> >
> > > While you can find the gamma-values of non-shape patterns in the paper
> > > of Remi, I can give you the list of shape-pattern gamma-values.
> > >
> > > The source-code is mixed with my engine-code, which i don't like to
> > > publish. But the algorithm is more or less easy to implement..
> > >
> > > I'll try to attach the file to this mail, if it don't work I send it to
> > > your address.
> > >
> > > The file have the following coding:
> > > It's a text-file with one pattern each line.
> > > Lines look as:
> > > Pattern-ID|Move-right(0=black, 1=white)|gamma-value\n
> > >
> > > The Pattern-IDs have the following coding:
> > > In the binary representation of the ID you have 2 Bits for every field.
> > > So you have 18 Bits at all.
> > > 00 = Empty, 01 = Black, 02 = White, 03 = Edge
> > > The pairs are ordered as:
> > > 1 2 3
> > > 4 5 6
> > > 7 8 9
> > > in the ID it is
> > > 123456789
> > >
> > > While you can rotate and mirror the patterns only one respresentation of
> > > the various possible representations is contained in the file.
> > >
> > > >
> > > > On Dec 5, 2007 3:17 PM, Lars <[EMAIL PROTECTED]> wrote:
> > > > Thank you for your explanations!
> > > > You were right, it was a bug, and now it works really fine.
> > > >
> > > > Are you (or Remi) willing to publish any of the following?
> > > > 1. Source code for extracting ELO ratings for moves
> > > > 2. Full list of gamma values, including patterns
> > > >
> > > >
> > > > Either of those would help kick start those of us that are just
> > > > starting to go down a similar road.
> > > > ___
> > > > 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] Re: Update of MoGo binary release, and windows version available! (repost)

[Edward de Grijs]

Thanks Hideki, Chris and Jacques for your replies.
 
> Hideki wrote:
> Then, you can make a very simple program that passes a file to stdout
> first and passes stdin to stdout after the end-of-file of the file.
> And use it as "a.out file | mogo ".
Is this not the way a "tail -f" works?
This is the method I use with gnugo to let te programs play against
each other. The communication between the programs and server program
are all using files. This seems fast enough, while I can check all
the communications which took place.
This tail -f fails in the same way.
 
To check things even more, I tried to communicate using C with popen():
> FILE *ptr;
> if ((ptr = popen("mogo --9 --nbTotalSimulations 3000 > mogoout", "w")) != 
> NULL)
> {
> fprintf(ptr, "boardsize 9\n");
> fprintf(ptr, "genmove b\n");
> sleep(60);
> }
 
But the result is the same, after these commands, mogo still continues to
perform multiple genmoves. I am puzzled here...
 
I will look at the ruby script, and there are also twogtp scripts of gnugo
in python, perl etc. which I could check.
 
Edward.
 
 
 
_
Probeer Live.nl 
Probeer Live.nl: zoekmachine van de makers van MSN! ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] low-hanging fruit

[Petr Baudis]

On Wed, Dec 05, 2007 at 10:16:20PM -0800, Sylvain Gelly wrote:
> >
> > You should be using area scoring only and if you are playing handicap
> > games then either YOU or MOGO is not counting them the same. Or
> > perhaps Mogo has a bug in the handicap code.
> >
> 
> MoGo uses KGS handicap counting (add 1 point to white for each handicap
> stone) if the GTP set_handicap_stones (approximate spelling) is called.

By the way, is KGS or SL right here? Is the correct white komi with
Chinese counting handicap_number or handicap_number/2?

(Note that in case of ING rules, the komi is handicap_number. Perhaps
whoever wrote this on the SL page was confused by the fact that half the
komi stones are placed in the opponent's territory when counting
manually?)

-- 
Petr "Pasky" Baudis
We don't know who it was that discovered water, but we're pretty sure
that it wasn't a fish.  -- Marshall McLuhan
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] cgos

[Nick Wedd]

In message <[EMAIL PROTECTED]>, Harri Salakoski 
<[EMAIL PROTECTED]> writes

Hi is last black move A4 really illegal in cgos rules?
Just ensure before start change things. It seemed weird.
White D9 shouls change board situation and white kills two stones 
before A4 is getting then

one stone back fine? t. harri

W A4
9 WW..W.WWW
8 ...W.W.W.
7 WBW..
6 WBBWBBWWW
5 .WWWB
4 BWBBB
3 .BBB.B.B.
2 B.B.B
1 .
ABCDEFGHJ

W D9
9 WW.WW.WWW
8 ...W.W.W.
7 WBW..
6 WBBWBBWWW
5 .WWWB
4 BWBBB
3 .BBB.B.B.
2 B.B.B
1 .
ABCDEFGHJ

B A5
9 WW.WW.WWW
8 ...W.W.W.
7 WBW..
6 WBBWBBWWW
5 BWWWB
4 BWBBB
3 .BBB.B.B.
2 B.B.B
1 .
ABCDEFGHJ

W A3
9 WW.WW.WWW
8 ...W.W.W.
7 WBW..
6 WBBWBBWWW
5 .WWWB
4 .WBBB
3 WBBB.B.B.
2 B.B.B
1 .
ABCDEFGHJ

B A4
9 WW.WW.WWW
8 ...W.W.W.
7 WBW..
6 WBBWBBWWW
5 .WWWB
4 BWBBB
3 .BBB.B.B.
2 B.B.B
1 .
ABCDEFGHJ


Here are the positions, edited to make them more legible:

W A4  [in fact it is B who has just played A4]

 O O . . O . O O O
 . . . O . O . O .
 O # O . O O O O .
 O # # O # # O O O
 . O O O # # # # #
 # O # # # # # # #
 . # # # . # . # .
 # . # # # # # . #
 # # # # # # # # .


W  D9  [Note this position, I will refer to it later]

 O O . O O . O O O
 . . . O . O . O .
 O # O . O O O O .
 O # # O # # O O O
 . O O O # # # # #
 # O # # # # # # #
 . # # # . # . # .
 # . # # # # # . #
 # # # # # # # # .


B  A5

 O O . O O . O O O
 . . . O . O . O .
 O # O . O O O O .
 O # # O # # O O O
 # O O O # # # # #
 # O # # # # # # #
 . # # # . # . # .
 # . # # # # # . #
 # # # # # # # # .


W  A3

 O O . O O . O O O
 . . . O . O . O .
 O # O . O O O O .
 O # # O # # O O O
 . O O O # # # # #
 . O # # # # # # #
 O # # # . # . # .
 # . # # # # # . #
 # # # # # # # # .


 B A4

 O O . O O . O O O
 . . . O . O . O .
 O # O . O O O O .
 O # # O # # O O O
 . O O O # # # # #
 # O # # # # # # #
 . # # # . # . # .
 # . # # # # # . #
 # # # # # # # # .


If "positional superko" is in force, this last move is illegal, as it 
recreates the position noted previously.


Nick
--
Nick Wedd[EMAIL PROTECTED]
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] ELO Ratings of move pattern

[Álvaro Begué]

Oh, I see you have applied the symmetries, but not the swapping of roles.
Still, this should probably be done and cut the number of gamma values in
half.

Álvaro.


On Dec 6, 2007 7:13 AM, Álvaro Begué <[EMAIL PROTECTED]> wrote:

> Thanks for the file! This should be very helpful when I try to reproduce
> results.
>
> It looks like you are not taking advantage of symmetries. For instance,
>
> 88|0|17.033168
> 88|1|12.263955
>
> and
>
> 164|0|17.388714
> 164|1|25.862695
>
> Are identical except for swapping the roles of white and black (88 == 1120
> in base 4, 164 == 2210 in base 4), and therefore they should have the same
> scores. If you do take symmetries of this type into consideration, you'll
> reduce the number of gamma values you have to compute by a factor of almost
> 16 (8 symmetries in the D4 group, times 2 colors). This should result in
> faster learning and better estimates.
>
> Álvaro.
>
>
>
> On Dec 6, 2007 4:28 AM, Lars <[EMAIL PROTECTED]> wrote:
>
> > While you can find the gamma-values of non-shape patterns in the paper
> > of Remi, I can give you the list of shape-pattern gamma-values.
> >
> > The source-code is mixed with my engine-code, which i don't like to
> > publish. But the algorithm is more or less easy to implement..
> >
> > I'll try to attach the file to this mail, if it don't work I send it to
> > your address.
> >
> > The file have the following coding:
> > It's a text-file with one pattern each line.
> > Lines look as:
> > Pattern-ID|Move-right(0=black, 1=white)|gamma-value\n
> >
> > The Pattern-IDs have the following coding:
> > In the binary representation of the ID you have 2 Bits for every field.
> > So you have 18 Bits at all.
> > 00 = Empty, 01 = Black, 02 = White, 03 = Edge
> > The pairs are ordered as:
> > 1 2 3
> > 4 5 6
> > 7 8 9
> > in the ID it is
> > 123456789
> >
> > While you can rotate and mirror the patterns only one respresentation of
> > the various possible representations is contained in the file.
> >
> > >
> > > On Dec 5, 2007 3:17 PM, Lars <[EMAIL PROTECTED]> wrote:
> > > Thank you for your explanations!
> > > You were right, it was a bug, and now it works really fine.
> > >
> > > Are you (or Remi) willing to publish any of the following?
> > > 1. Source code for extracting ELO ratings for moves
> > > 2. Full list of gamma values, including patterns
> > >
> > >
> > > Either of those would help kick start those of us that are just
> > > starting to go down a similar road.
> > > ___
> > > 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] ELO Ratings of move pattern

[Álvaro Begué]

Thanks for the file! This should be very helpful when I try to reproduce
results.

It looks like you are not taking advantage of symmetries. For instance,

88|0|17.033168
88|1|12.263955

and

164|0|17.388714
164|1|25.862695

Are identical except for swapping the roles of white and black (88 == 1120
in base 4, 164 == 2210 in base 4), and therefore they should have the same
scores. If you do take symmetries of this type into consideration, you'll
reduce the number of gamma values you have to compute by a factor of almost
16 (8 symmetries in the D4 group, times 2 colors). This should result in
faster learning and better estimates.

Álvaro.


On Dec 6, 2007 4:28 AM, Lars <[EMAIL PROTECTED]> wrote:

> While you can find the gamma-values of non-shape patterns in the paper
> of Remi, I can give you the list of shape-pattern gamma-values.
>
> The source-code is mixed with my engine-code, which i don't like to
> publish. But the algorithm is more or less easy to implement..
>
> I'll try to attach the file to this mail, if it don't work I send it to
> your address.
>
> The file have the following coding:
> It's a text-file with one pattern each line.
> Lines look as:
> Pattern-ID|Move-right(0=black, 1=white)|gamma-value\n
>
> The Pattern-IDs have the following coding:
> In the binary representation of the ID you have 2 Bits for every field.
> So you have 18 Bits at all.
> 00 = Empty, 01 = Black, 02 = White, 03 = Edge
> The pairs are ordered as:
> 1 2 3
> 4 5 6
> 7 8 9
> in the ID it is
> 123456789
>
> While you can rotate and mirror the patterns only one respresentation of
> the various possible representations is contained in the file.
>
> >
> > On Dec 5, 2007 3:17 PM, Lars <[EMAIL PROTECTED]> wrote:
> > Thank you for your explanations!
> > You were right, it was a bug, and now it works really fine.
> >
> > Are you (or Remi) willing to publish any of the following?
> > 1. Source code for extracting ELO ratings for moves
> > 2. Full list of gamma values, including patterns
> >
> >
> > Either of those would help kick start those of us that are just
> > starting to go down a similar road.
> > ___
> > 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] Re: The global search myth

[Jacques Basaldúa]

Dave Dyer wrote:

In cases where the good moves are the "obvious" ones, 
you've found them anyway.  


Ok. Here I agree.

In other cases, you prune them away.   


You are not really pruning, just postponing. Of course
you may overlook moves of genius, who doesn't? But
if your probabilities are correct you may be emulating
what a human does.


You DO get wrong answers much faster this way though.


Why? I don't see why. I see this order as the most 
human like way of searching. As any incomplete search,
it can blunder, but why more than any other incomplete 
search?



Jacques.


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

[computer-go] Redirecting i/o in the Windows version of Mogo (Was in Re: Update of MoGo binary ..)

[Jacques Basaldúa]

Edward de Grijs wrote:


Can someone help me with this problem, for which I cannot
find a solution: I am trying to run MoGo in an automatic 
way, using the cygwin toolkit.


I guess you are trying to do this in Windows and using
the Windows binary. If this is the case, you don't need
any library. I did it and it works.

Now, Linux supporters will enjoy this ;-), even as a 
Windows programmer I must admit that redirecting

console i/o is one of the weirdest Windows "features".

The official Win32 reference example explaining how to do 
this has 245 lines of code!! (although many are remarks)


If you have the Win32 reference in .hlp format search
an article titled "Creating a Child Process with Redirected 
Input and Output". If you don't, it must be public at MSDN.



Jacques.

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

[computer-go] ELO Ratings of move pattern

[Jacques Basaldúa]

Lars wrote:

> Anyone of you have similar or other experiences with the algorithm?

I use at runtime the same Bradley-Terry formulas Remí introduces
in his paper. That is a huge advance compared to "naif urgency"
scores because it gives a measure of how hard it was to "win"
for a move candidate. But I use a much simpler offline learning
algorithm: Compute the "naif" score just as standard:

 sc[0] = (times played)/(times played + times postponed)

Use this as an a priori value of the score. Then, iterating through
all the games many times, create a compensation weight CW
rewarding scores winning positions with high total of concurrent
scores and diminishing those won "too easily". Since the
efficiency of the offline part of the program is not an issue,
I make these in small steps iterating many times until they
do almost nothing. Each time, I compare observed versus
expected number of right guesses to see if it improves or not.

   sc[i] = CW*sc[i - 1]  // * is elem by elem mul of a vector

I guess it gets to more or less the same. Sure Remí's solution
is more efficient and elegant.


2 more issues I am concerned about patterns:


MIAI URGENCY: When two (or maybe more) moves are
extremely urgent, but it is not important which of the two
because they are equivalent. In this case the high urgency
is masked by the fact that it is divided between two moves.


IMPLICITLY CHECKED URGENCY: When an urgent
pattern was already on the board and was not played its
score is overestimated. Imagine threatening a bamboo joint,
preserving the connection may be a huge point when it saves
a big group without eyespace. But it may also be worth nothing
when both groups are dead. When it first appears, there is
a high probability that it is big and, therefore, its urgency should
be high. But, if it wasn't played, then it is probably not big.
The next times it has to be considered much less urgent than
the first time.


Jacques.


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

Re: [computer-go] ELO Ratings of move pattern

[Lars]

While you can find the gamma-values of non-shape patterns in the paper
of Remi, I can give you the list of shape-pattern gamma-values. 

The source-code is mixed with my engine-code, which i don't like to
publish. But the algorithm is more or less easy to implement..

I'll try to attach the file to this mail, if it don't work I send it to
your address.

The file have the following coding:
It's a text-file with one pattern each line.
Lines look as:
Pattern-ID|Move-right(0=black, 1=white)|gamma-value\n

The Pattern-IDs have the following coding:
In the binary representation of the ID you have 2 Bits for every field.
So you have 18 Bits at all. 
00 = Empty, 01 = Black, 02 = White, 03 = Edge
The pairs are ordered as:
1 2 3
4 5 6 
7 8 9
in the ID it is 
123456789

While you can rotate and mirror the patterns only one respresentation of
the various possible representations is contained in the file.

> 
> On Dec 5, 2007 3:17 PM, Lars <[EMAIL PROTECTED]> wrote:
> Thank you for your explanations!
> You were right, it was a bug, and now it works really fine.
> 
> Are you (or Remi) willing to publish any of the following?
> 1. Source code for extracting ELO ratings for moves 
> 2. Full list of gamma values, including patterns
> 
> 
> Either of those would help kick start those of us that are just
> starting to go down a similar road.
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
0|0|1.337276
0|1|1.463386
1|0|0.821361
1|1|1.215388
2|0|1.525746
2|1|0.915657
4|0|0.141457
4|1|1.142958
5|0|0.056205
5|1|0.115909
6|0|7.583881
6|1|11.390228
8|0|1.448231
8|1|0.152809
9|0|11.164488
9|1|7.374229
10|0|0.146238
10|1|0.10
17|0|0.366759
17|1|2.434563
18|0|2.148817
18|1|1.627508
21|0|0.087161
21|1|0.014422
22|0|0.770173
22|1|2.185607
25|0|14.664877
25|1|13.326480
26|0|2.076489
26|1|0.724617
34|0|3.128791
34|1|0.695057
38|0|15.872605
38|1|19.136591
42|0|0.047098
42|1|0.080331
63|0|0.602812
63|1|0.599073
68|0|0.010518
68|1|0.056378
69|0|0.039757
69|1|0.025453
70|0|3.689207
70|1|4.644702
72|0|7.211424
72|1|6.849938
73|0|5.236492
73|1|4.371632
74|0|3.996832
74|1|5.530713
80|0|0.144926
80|1|1.117219
81|0|0.147169
81|1|0.063468
82|0|6.346052
82|1|6.961566
84|0|0.058657
84|1|0.040099
85|0|0.030839
85|1|0.019321
86|0|1.309600
86|1|1.500465
88|0|17.033168
88|1|12.263955
89|0|4.103983
89|1|2.438694
90|0|17.843928
90|1|14.266457
96|0|0.608897
96|1|1.928170
97|0|0.180138
97|1|0.659119
98|0|6.382083
98|1|8.727558
100|0|0.101635
100|1|2.991378
101|0|0.175208
101|1|0.470863
102|0|10.657266
102|1|7.203067
104|0|0.755620
104|1|2.114244
105|0|0.868711
105|1|1.475836
106|0|0.762084
106|1|2.133980
127|0|0.483525
127|1|1.042185
136|0|0.147151
136|1|0.055962
137|0|4.214510
137|1|3.872336
138|0|0.028973
138|1|0.042606
144|0|1.936984
144|1|0.434265
145|0|8.268620
145|1|6.193287
146|0|0.705437
146|1|0.125423
148|0|1.701870
148|1|0.699731
149|0|1.807236
149|1|0.747623
150|0|1.248414
150|1|1.099761
152|0|3.314570
152|1|0.296935
153|0|5.442849
153|1|9.916852
154|0|0.676057
154|1|0.093327
160|0|1.358711
160|1|0.235558
161|0|7.245779
161|1|6.030085
162|0|0.232468
162|1|0.275834
164|0|17.388714
164|1|25.862695
165|0|15.389015
165|1|16.885338
166|0|4.025276
166|1|5.135984
168|0|0.082821
168|1|0.036868
169|0|1.455682
169|1|1.060028
170|0|0.021015
170|1|0.033832
191|0|0.681340
191|1|0.158868
1088|0|0.016235
1088|1|0.200130
1089|0|0.053096
1089|1|0.125987
1090|0|1.122111
1090|1|3.304599
1092|0|0.062217
1092|1|0.043887
1093|0|0.060291
1093|1|0.040833
1094|0|0.035873
1094|1|0.047407
1096|0|18.644308
1096|1|14.124012
1097|0|3.250391
1097|1|5.927136
1098|0|3.976621
1098|1|5.319631
1105|0|0.055604
1105|1|0.039032
1106|0|1.051800
1106|1|1.991137
1109|0|0.165100
1109|1|0.099835
1110|0|0.061302
1110|1|0.137576
1113|0|1.586970
1113|1|0.920393
1114|0|5.170633
1114|1|5.236513
1122|0|3.587595
1122|1|7.485036
1126|0|8.498618
1126|1|1.365394
1130|0|2.478299
1130|1|7.161664
1152|0|0.747669
1152|1|0.612379
1153|0|4.957357
1153|1|4.337732
1154|0|0.304130
1154|1|0.572912
1156|0|1.222179
1156|1|0.500764
1157|0|1.181008
1157|1|0.649722
1158|0|0.493950
1158|1|1.752506
1160|0|0.725725
1160|1|1.067260
1161|0|13.675577
1161|1|17.139254
1162|0|0.131324
1162|1|0.132472
1168|0|0.475614
1168|1|0.293579
1169|0|2.236877
1169|1|2.252444
1170|0|0.103995
1170|1|0.161446
1172|0|0.441323
1172|1|0.482981
1173|0|0.323594
1173|1|0.183294
1174|0|0.371224
1174|1|0.218636
1176|0|2.159709
1176|1|0.512112
1177|0|4.894608
1177|1|3.394627
1178|0|0.108785
1178|1|0.118652
1184|0|5.325184
1184|1|3.915404
1185|0|5.412484
1185|1|5.394289
1186|0|1.818187
1186|1|1.486370
1188|0|15.435468
1188|1|11.920771
1189|0|6.302822
1189|1|3.997952
1190|0|4.232445
1190|1|5.407879
1192|0|0.962175
1192|1|0.958373
1193|0|3.686631
1193|1|6.168996
1194|0|0.111840
1194|1|0.299301
2176|0|0.285916
2176|1|0.016638
2177|0|3.524956
2177|1|1.176991
2178|0|0.168611
2178|1|0.020890
2180|0|13.391322
2180|1|1