Re: [Computer-go] Our Silicon Overlord

[Gonçalo Mendes Ferreira]

Well, I don't know what is the likelihood of being hit by drunk drivers
or AI driven cars, but if it were the same I'd prefer to have drunk
drivers. Drunk drivers you can understand: you can improve your chances
by making yourself more visible, do not jump from beyond obstacles, be
more careful when crossing or not crossing before they actually stop. A
failure in an AI car seems much more unpredictable.

Gonçalo

On 07/01/2017 21:24, Xavier Combelle wrote:
> 
>> ...this is a major objective. E.g., we do not want AI driven cars
>> working right most of the time but sometimes killing people because
>> the AI faces situations (such as a local sand storm or a painting on
>> the street with a fake landscape or fake human being) outside its
>> current training and reading. 
> currently I don't like to be killed by a drunk driver, and to my opinion
> it is very more likely to happen than an AI killing me because a mistake
> in programming (I know, it is not the point of view of most of people
> which want a perfect AI with zero dead and not an AI which would reduce
> the death on road by a factor 100)
> ___
> Computer-go mailing list
> Computer-go@computer-go.org
> http://computer-go.org/mailman/listinfo/computer-go
> 
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Time policy

[Gonçalo Mendes Ferreira]

I similarly use C x (T / E) in matilda, with
C = 1.24
T = time left on current period (absolute or byo yomi)
E = argmax(estimate of game length divided by two ; 19) or byo yomi stones 
remaining

The length estimate ir around 2/3 of the board points.

It lacks the decision to expend a byo yomi period in more difficult positions.


Gonçalo FerreiraEm 04/11/2016 08:40, Urban Hafner  
escreveu:
>
> I think there are some short papers about it out there. But I would suggest 
> looking at the source code of existing bots like michi or pachi. What I use 
> in my bot is really simple. I use the following formula:
>
> time for next move = remaining time / (C * max(vacant points, M))
>
> Where C is some constant you need to figure out (I use 0.5 right now), 
> “vacant points” is the number of empty intersections on the board and M is a 
> lower limit (I currently use 24) so that you don’t use up too much time that 
> you might need when a capture happens.
>
> It has worked well enough so far that I haven’t looked at more intricate 
> algorithms. Oh, and once I hit byo-yomi time I just divide the time into 
> equal parts by the number of stones for the byo-yomi period.
>
> Urban
>
> On Fri, Nov 4, 2016 at 9:00 AM, Gian-Carlo Pascutto  wrote:
>>
>> On 04-11-16 04:45, Billy White wrote:
>> > Hi,
>> >
>> > Our team is working on a computer go system mainly followed alphago.
>> > We try to add time policy to our system but cannot find something
>> > useful.
>> >
>> > I am wondering whether there are some useful material?
>>
>> Take a large games database, and construct a table of expected number of
>> moves remaining based on the current move of the game.
>>
>> Divide total amount of time left by the output of that table.
>>
>> Test if biasing it to think slightly longer early on helps playing strength.
>>
>> If there is byo-yomi time. the required extra thinking time generally
>> flows logically from the byo-yomi timecontrol and the above.
>>
>> --
>> GCP
>> ___
>> Computer-go mailing list
>> Computer-go@computer-go.org
>> http://computer-go.org/mailman/listinfo/computer-go
>
>
>
>
> -- 
> Blog: http://bettong.net/
> Twitter: https://twitter.com/ujh
> Homepage: http://www.urbanhafner.com/___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] GoGui dead?

[Gonçalo Mendes Ferreira]

I use GoGui. Does it matter if it is updated? The GTP is still in draft
after 14 years.

Gonçalo

On 03/10/2016 20:26, David Ongaro wrote:
> The GoGui Website on "http://gogui.sourceforge.net 
> “ states: "This software is no longer actively 
> developed or supported.” And Indeed there doesn’t seem to be any updates 
> since beginning of the year (and that is after a 2 year hiatus).
> 
> So what are you using as an open source GTP client?
> 
> Thanks,
> 
> David O.
> 
> 
> 
> 
> ___
> Computer-go mailing list
> Computer-go@computer-go.org
> http://computer-go.org/mailman/listinfo/computer-go
> 
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Bug with resigned games in gogui-twogtp

[Gonçalo Mendes Ferreira]

This happens in 1.4.9 too. The game result is written relative to the
original colors in the SGF and .dat files; but the plays and player
names and versions are switched in the SGF.

Test results should be fine as long and you don't go over every file
checking the last play to tell who won.

Gonçalo

On 07/09/2016 17:42, valky...@phmp.se wrote:
> Hi,
> 
> I just think I found a bug in twogtp 1.4.8 (windows), using the
> -alternate flag and two programs that always resign if losing.
> 
> Basically the winner is wrong in the SGF files, and also in the logs.
> The bug seems to happen only for odd games. It is easy to see because
> when a program resigns the other progtam that played the last move
> should be the winner.
> 
> So by loading sgf's and go to the end of the game, the winner of the
> game should always be the player who played last.
> 
> I also inspected the GTP logs with -verbose and verfied that the program
> resigned correctly.
> 
> 
> I post this here because this may affect a lot of go programmer who has
> might have random noise in test results that might be hard to notice.
> (Also was not able to find out quickly where to post on GoGui website).
> 
> Best
> Magnus Persson
> ___
> Computer-go mailing list
> Computer-go@computer-go.org
> http://computer-go.org/mailman/listinfo/computer-go
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

[Computer-go] Commonsense Go

[Gonçalo Mendes Ferreira]

Hello, I'm sharing with you a document that was shared in the GNU Go
mailing list and I found interesting. Its author is currently muted from
this list, but I think it is very much worth sharing here instead.

There haven't been many papers on a classical approach to Go in recent
years (decade?).

Here it is
http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2818149

The original thread can be found at
http://lists.gnu.org/archive/html/gnugo-devel/2016-08/msg2.html

Cheers,
Gonçalo


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

Re: [Computer-go] June KGS bot tournament: 9x9

[Gonçalo Mendes Ferreira]

Hi there, thanks for your tireless work as usual.

Also, do you mean that the formal division will use Swiss, or that we
are back to just a single division?

Gonçalo

On 09/06/2016 21:19, Nick Wedd wrote:
> The June KGS bot tournament will start on Sunday, June 19th, at 08:00 UTC
> and end by 14:40 UTC.  It will use 9x9 boards, with time limits of 9
> minutes each plus very fast Canadian overtime, and komi of 7.  See
> http://www.gokgs.com/tournInfo.jsp?id=1044
> 
> It will be a Swiss tournament, as usual.  My investigation of the McMahon
> format, as implemented on KGS, found no advantage over Swiss, and some
> disadvantages.
> 
> Please register by emailing me, with the words "KGS Tournament Registration"
> in the email title, at mapr...@gmail.com .
> 
> Nick
> 
> 
> 
> ___
> Computer-go mailing list
> Computer-go@computer-go.org
> http://computer-go.org/mailman/listinfo/computer-go
> 
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] May KGS bot tournament

[Gonçalo Mendes Ferreira]

Has the number of programs risen that much?

I'd prefer not adding self-declared ranking limitations, though as a
spectator handicap matches are interesting.

Anyways, Urban, I can enter my program too if you want, it is well
bellow GNU Go in 19x19.

Gonçalo

On 04/05/2016 15:27, Erik van der Werf wrote:
> Or switch to McMahon / Handicaps
> 
> On Wed, May 4, 2016 at 4:18 PM, Sebastian Scheib 
> wrote:
> 
>> That would be good, something like in other sports where you have a first,
>> second and so... categories.
>>
>> 2016-05-04 11:00 GMT-03:00 Jim O'Flaherty :
>>
>>> Hmmm...if bots weaker than GnuGo are actively discouraged, perhaps there
>>> could be a separate tournament level for that grouping of "aspiring
>>> computer Go" entrants (if it isn't too much extra work). Having bots earn
>>> the right to move into the higher level of (i.e. have met the entry
>>> requirement of "consistently beats GnuGo version X.Y) might be a nice
>>> filter as the number of those desiring to participate (with weaker bots)
>>> rises.
>>>
>>> On Wed, May 4, 2016 at 4:01 AM, Urban Hafner 
>>> wrote:
>>>
 I’m considering entering with my bot but it’s rather weak (a lot weaker
 than GnuGo on 19x19) so I don’t know if it makes sense. Unless of course
 other weaker bots were willing to enter as well. If no one is interested in
 this (or if it’s even discouraged by Nick) then I would refrain from
 entering tournaments that I have no chance in beating GnuGo.

 Urban

 On Mon, May 2, 2016 at 6:51 PM, Nick Wedd  wrote:

> The May KGS bot tournament will start on Sunday, May 8th at 16:00 UTC,
> and finish by 22:00 UTC.  It will use 19x19 boards, with time limits
> of 14 minutes each plus very fast Canadian overtime, and komi of 7.5.
> See http://www.gokgs.com/tournEntrants.jsp?id=1030
>
> Please register by emailing me, with the words "KGS Tournament 
> Registration"
> in the email title, at mapr...@gmail.com .
>
> Nick
> --
> Nick Wedd  mapr...@gmail.com
>
> ___
> Computer-go mailing list
> Computer-go@computer-go.org
> http://computer-go.org/mailman/listinfo/computer-go
>



 --
 Blog: http://bettong.net/
 Twitter: https://twitter.com/ujh
 Homepage: http://www.urbanhafner.com/

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

>>>
>>>
>>> ___
>>> Computer-go mailing list
>>> Computer-go@computer-go.org
>>> http://computer-go.org/mailman/listinfo/computer-go
>>>
>>
>>
>>
>> --
>> Dracux
>> *http://www.dracux.com *
>>
>> ___
>> Computer-go mailing list
>> Computer-go@computer-go.org
>> http://computer-go.org/mailman/listinfo/computer-go
>>
> 
> 
> 
> ___
> Computer-go mailing list
> Computer-go@computer-go.org
> http://computer-go.org/mailman/listinfo/computer-go
> 
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Operators for Frisbee Go Simulation

[Gonçalo Mendes Ferreira]

Hm interesting question.

komi
8.0   49%
7.5   50%
7.0   51%
3.5   56%
1.5   58%
1.0   60%
0.5   61%
0.0   61%

Also these win rates do not include the probability of drawing.

Gonçalo

On 14/04/2016 18:08, "Ingo Althöfer" wrote:
> Hi Goncalo,
> 
>>  accuracy p
>> komi  0.5  0.2
>> 7.5   31%  22%
>> 3.5   43%  36%
>> 1.5   48%  45%
>> 1.0   49%  47%
>> 0.5   51%  49%
>> 0.0   52%  51%
> 
> Interesting.
> 
> Concerning your bot in "normal" 9x9-Go:
> Which win rates do you get there for different komi values?
> 
> Ingo.
> ___
> Computer-go mailing list
> Computer-go@computer-go.org
> http://computer-go.org/mailman/listinfo/computer-go
> 
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Operators for Frisbee Go Simulation

[Gonçalo Mendes Ferreira]

>>> On frisbee Go itself I used the following definition:
>>> 1. An intended play must be legal -- no playing on top of a stone hoping
>>> it 'falls' to the neighbor positions.
>>
>> Accepted.
>
> What's the point of this rule?

The point of the rule is ease of implementation for computer programs,
to promote adoption. A program that already plays Go will probably keep
tabs on legal plays, not every board intersection, so this rule reduces
the scope of things that need to be changed.

I also had another restriction in my program that I forgot to mention:
6. Both players must be using the same probability p.

Again for ease of implementation.

In testing I've also noted that a komi of 7.0 or 7.5 is no longer
reasonable in Frisbee Go...

Cheers,
Gonçalo



On 14/04/2016 14:41, John Tromp wrote:
>>> On frisbee Go itself I used the following definition:
>>> 1. An intended play must be legal -- no playing on top of a stone hoping
>>> it 'falls' to the neighbor positions.
>>
>> Accepted.
> 
> What's the point of this rule?
> 
> I feel it is an unnecessary restriction, similar to the no-suicide rule,
> and would vote against it.
> 
> As I said before, it suffices to have positive probability of a legal move.
> 
> In real life frisbee go, a player doesn't need to state his intended throwing
> target, so if it ends up landing in a legal place, it's accepted, regardless
> of whether it was aimed there, or at a possibly occupied neighbour.
> 
> regards,
> -John
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Beginner question : how to choose a board representation

[Gonçalo Mendes Ferreira]

There isn't a lot of info on this[1], so it will probably be a hard
journey for a fast representation. But the things a Go board
representation usually focus on are

1. simulating play and then undoing (or telling what happens after a
play: liberties left, stone captures)
2. fast pattern hashing
3. ascertaining qualities of groups of stones, safety, neighbors, etc

The need for these things makes itself apparent little by little.

Pachi has its state representation commented a lot, maybe even too much:
https://github.com/pasky/pachi/blob/master/board.h

I think the starting point of any representation is that a single point
is needed for testing ko. :-)

[1] Some actual examples:
Emil H.J. Nijhuis's thesis, "Learning Patterns in the Game of Go"
Martin Müller, "Computer Go" (2002)
https://www.gnu.org/software/gnugo/gnugo_17.html
https://www.gnu.org/software/gnugo/gnugo_15.html

Gonçalo


On 10/04/2016 09:00, Oliver Lewis wrote:
> There's a discussion of some of the issues in Petr Baudis' PhD thesis:
> http://pachi.or.cz/
> 
> 
> 
> On Sun, Apr 10, 2016 at 9:19 AM, Jean-Francois Romang 
> wrote:
> 
>> Hello to everyone ; I'm a newcomer in this list and computer go
>> programming. I have a chess programming background, but I want to start
>> something new. :-)
>> I'm currently in the early phases of developing GTP compatible go engine ;
>> now it's time for me to choose a board representation : are there some
>> articles or tips on this ?
>> Thanks,
>> Jean-Francois
>> ___
>> Computer-go mailing list
>> Computer-go@computer-go.org
>> http://computer-go.org/mailman/listinfo/computer-go
> 
> 
> 
> ___
> Computer-go mailing list
> Computer-go@computer-go.org
> http://computer-go.org/mailman/listinfo/computer-go
> 
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Operators for Frisbee Go Simulation

[Gonçalo Mendes Ferreira]

Hello Ingo, if possible I'd like an operator for my program. I'd help
him/her remotely before Leiden.

I'm also letting everyone know my program now has the minimum effort for
frisbee Go (https://bitbucket.org/gonmf/matilda/). I'm looking for other
programs that I can test it with. I lack both a sparring partner and
connecting software, so it is likely very poor right now.

On frisbee Go itself I used the following definition:
1. An intended play must be legal -- no playing on top of a stone hoping
it 'falls' to the neighbor positions.
2. Unintentional plays that are illegal are nulled and don't imply a
desire to end the match.
3. The distribution of unintentional plays around the 4 neighbors is
constant even at the border where there are never 4 neighbors; "You hit
the target with prob. p, and its 4 neighbours with probability
(1-p)/4.". The residual probability at the border is not reused for
on-board plays.
4. Probability parameter p cannot be changed midgame, for simplification.
5. Technically, using the GTP, I assumed genmove_reg+play commands are
used, instead of genmove+undo+play or something frisbee specific. This
is probably stating the obvious.

Gonçalo


On 06/04/2016 14:54, "Ingo Althöfer" wrote:
> Hello,
> one of the games in the Computer Olympiad in Leiden
> (June 27 till July 03, 2016) will be "Frisbee Go Simulation"
> on 9x9 boards. 
> 
> I am willing to operate one "foreign" program (David Fotlands
> bot is my first choice). And I will find operators for one 
> or two other programs, when I know until end of next week (the
> operators I have in mind have to make their hotel bookings (special
> rate) rather soon).
> 
> Please, let me know if you need an operator for the Frisbee Go 
> simulation bot.
> 
> Cheers, Ingo.
> ___
> Computer-go mailing list
> Computer-go@computer-go.org
> http://computer-go.org/mailman/listinfo/computer-go
> 
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] new challenge for Go programmers

[Gonçalo Mendes Ferreira]

Come on let's all calm down please. :)

David I think the great challenge is in having good insight with AlphaGo
strength. Many Faces already provides some textual move suggestions, as
do probably other programs. Any program that doesn't use exclusively
machine learning or global search, like GNU Go, should be able to
suggest how it came about a move.

Unfortunately no one has a clue on how to put into words what DCNN
"know", to produce really meaningful and useful feedback, justifying
decisions around candidates, etc. This is very much worth investigating.

- Gonçalo



On 30/03/2016 12:32, Álvaro Begué wrote:
>> no lack of respect for DeepMind's achievement was contained in my
>> posting; on the contrary, i was as surprised as anyone at how well she
>> did and it gave me great pause for thought.
>>
> 
> Well, you wrote this:
> 
>> but convolutional neural networks and monte-carlo simulators have not
>> advanced the science of artificial intelligence one whit further than
>> being engineered empirical validations of the 1940s-era theories of
>> McCullough & Pitts and Ulam respectively, albeit their conjunction
>> being a seminal validation insofar as duffing up human Go players is
>> concerned.
>>
> 
> That paragraph is disrespectful of AlphaGo and every important development
> that it was built on. Theorists of the 40s didn't know jackshit about how
> to make a strong go program or any other part of AI, for that matter.
> 
> This is like giving credit to the pre-Socratic philosophers for atomic
> theory, or to Genesis for the Big Bang theory. I am sure there are people
> that see connections, but no. Just no.
> 
> one has to expect a certain amount of abuse when going public, and to
>> expect that eager critics will misrepresent what was said.
>>
> 
> Your vast experience in the field means your opinions were formed way
> before we knew what works and what doesn't, and are essentially worthless.
> 
> There, you like abuse?
> 
> Álvaro.
> 
> 
> On Wed, Mar 30, 2016 at 6:04 AM, djhbrown .  wrote:
> 
>> one has to expect a certain amount of abuse when going public, and to
>> expect that eager critics will misrepresent what was said.
>>
>> no lack of respect for DeepMind's achievement was contained in my
>> posting; on the contrary, i was as surprised as anyone at how well she
>> did and it gave me great pause for thought.
>>
>> as to preconceived notions, my own notions are postconceived, having
>> studied artificial intelligence and biological computation over 40
>> post-doctoral years during which i have published 50 or so
>> peer-reviewed scientific papers, some in respectable journals,
>> including New Scientist.
>>
>> On 30/03/2016, Stefan Kaitschick  wrote:
>>> Your lack of respect for task performance is misguided imo. Your
>>> preconceived notions of what intelligence is, will lead you astray.
>>>
>>
>>
>> --
>> patient: "whenever i open my mouth, i get a shooting pain in my foot"
>> doctor: "fire!"
>> http://sites.google.com/site/djhbrown2/home
>> https://www.youtube.com/user/djhbrown
>> ___
>> Computer-go mailing list
>> Computer-go@computer-go.org
>> http://computer-go.org/mailman/listinfo/computer-go
>>
> 
> 
> 
> ___
> Computer-go mailing list
> Computer-go@computer-go.org
> http://computer-go.org/mailman/listinfo/computer-go
> 
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Michi port

[Gonçalo Mendes Ferreira]

A look at GitHub tells me it has been ported to C, Rust and Go.

To C# it appears to have been started here:
https://github.com/radiatoryang/michi-csharp

- Gonçalo


On 19/03/2016 19:19, Andreas Persson wrote:
> Hi all, thought I would give Go AI another shot after seeing the great 
> AlphaGo 
> games :) Has anyone done a port of Michi for C# or Java? Would love to get a 
> hold of it if so, otherwise I will probably do a C# port myself.
> 
> Cheers, Andreas
> 
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] computergo.org

[Gonçalo Mendes Ferreira]

I don't know how up-to-date computer-go.info is, but it appears a better
target for redirecting.

- Gonçalo

On 18/03/2016 19:46, Xavier Combelle wrote:
> 2016-03-17 16:16 GMT+01:00 Joshua Shriver :
> 
>> Does anyone have interest in that domain name? I'd be willing to
>> transfer it to a new owner for free.  It came up a year or so back and
>> I grabbed it just in case but never used it.
>>
>> Rather see it go to someone who can use it rather than squat. It's
>> already for another year.
>>
>> -Josh
>> ___
>> Computer-go mailing list
>> Computer-go@computer-go.org
>> http://computer-go.org/mailman/listinfo/computer-go
> 
> 
> I would vote for redirecting to computer-go.org if everybody agree (or the
> other direction should be good too)
> 
> 
> 
> ___
> Computer-go mailing list
> Computer-go@computer-go.org
> http://computer-go.org/mailman/listinfo/computer-go
> 
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] computergo.org

[Gonçalo Mendes Ferreira]

Instead of just redirecting, it could be a directory page for:
- various Nick Wedd pages
- CGOS
- mailing lists
- the game AI forum
- news sites
- aggregators of tournament information, ICGA
- aggregator or list of upcoming conferences
- links to software and tools
- lists of publications, Martin Müller's page, etc

Gonçalo


On 19/03/2016 01:07, Joshua Shriver wrote:
> Agree, main reason I snagged it was mostly to make sure it would be
> used and not end up some spam or adult site.
> 
> I do like the idea of re-directing and that could be done in minutes.
> Which do you feel is better the host of this list, or the .info one?
> 
> -Josh
> 
> On Fri, Mar 18, 2016 at 4:58 PM, David Doshay <ddos...@mac.com> wrote:
>> sorry about that auto-correct ‘typo. The first one is supposed to be 
>> computergo.org, but that should be clear anyway ...
>>
>> Cheers,
>> David G Doshay
>>
>> ddos...@mac.com
>>
>>
>>
>>
>>
>>> On 18, Mar 2016, at 1:56 PM, David Doshay <ddos...@mac.com> wrote:
>>>
>>> From my perspective, having both a computer.org and a computer-go.org seems 
>>> redundant.
>>>
>>> Cheers,
>>> David G Doshay
>>>
>>> ddos...@mac.com
>>>
>>>
>>>
>>>
>>>
>>>> On 18, Mar 2016, at 12:49 PM, Gonçalo Mendes Ferreira <go...@sapo.pt> 
>>>> wrote:
>>>>
>>>> I don't know how up-to-date computer-go.info is, but it appears a better
>>>> target for redirecting.
>>>>
>>>> - Gonçalo
>>>>
>>>> On 18/03/2016 19:46, Xavier Combelle wrote:
>>>>> 2016-03-17 16:16 GMT+01:00 Joshua Shriver <jshri...@gmail.com>:
>>>>>
>>>>>> Does anyone have interest in that domain name? I'd be willing to
>>>>>> transfer it to a new owner for free.  It came up a year or so back and
>>>>>> I grabbed it just in case but never used it.
>>>>>>
>>>>>> Rather see it go to someone who can use it rather than squat. It's
>>>>>> already for another year.
>>>>>>
>>>>>> -Josh
>>>>>> ___
>>>>>> Computer-go mailing list
>>>>>> Computer-go@computer-go.org
>>>>>> http://computer-go.org/mailman/listinfo/computer-go
>>>>>
>>>>>
>>>>> I would vote for redirecting to computer-go.org if everybody agree (or the
>>>>> other direction should be good too)
>>>>>
>>>>>
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Congratulations to AlphaGo

[Gonçalo Mendes Ferreira]

The single machine version and the 2000 machine version is apparently a
difference in 150 ELO, so maybe a 32 core instance in Amazon would be
close enough, costing about 1200$ a month. Maybe it's doable, or for a
Tokyo U. or BGA or AGA to set up something like this with Google permission.

On 13/03/2016 00:24, Lukas van de Wiel wrote:
> This would be many thousands of dollars per day. A single game would be
> more than a thousand dollars in total costs.
> I do not think a kickstarter project or so would be successful, as the go
> community is simply not *that* big...
> 
> On Sun, Mar 13, 2016 at 1:17 PM, Gonçalo Mendes Ferreira <go...@sapo.pt>
> wrote:
> 
>> It does seem unlikely for DeepMind not to move on to "bigger" things,
>> but maybe the Go community can make some kind of fundraiser to keep an
>> instance of AlphaGo playing 24/7? I think there are some websites for
>> this kind of thing. Someone would be in charge of scheduling time for it
>> to play pros, other programs, and maybe play online on breaks. Just an
>> idea, oh Google overlords that watch all communications.
>>
>> Gonçalo
>>
>> On 13/03/2016 00:06, Lukas van de Wiel wrote:
>>> Oh, I did not say that it would not be beneficial, to AlphaGo, and to the
>>> people playing it, and to the Go community as a whole, but still, it will
>>> have to come from somewhere. Just the electricity bill alone would be
>>> hair-raising.
>>> And the big-scale benefits in prestige and marketing are over, with this
>>> victory.
>>>
>>> It would be cool to build on the works of AlphaGo, and I would like to
>> see
>>> it as much as the next enthusiast, but I doubt the feasibility...
>>>
>>> On Sun, Mar 13, 2016 at 1:01 PM, Thomas Wolf <tw...@brocku.ca> wrote:
>>>
>>>>
>>>>
>>>> On Sat, 12 Mar 2016, Lukas van de Wiel wrote:
>>>>
>>>> And the hardware available for this tournament was tremendous. It
>> remains
>>>>> to be seen whether the hardware and the people
>>>>> maintaining it would be available for a longer period. The costs of
>> this
>>>>> are not to be underestimated. Who would pay it?
>>>>>
>>>>
>>>> The AlphaGo team would get feedback from testing by players with very
>>>> different ideas/strengths who they would otherwise never get in contact
>>>> with.
>>>>
>>>> For example, Michael Redmond mentioned repeatedly in the last 3 reviews
>>>> that
>>>> he would love to play AlphaGo to study Go, to find new openings,...
>>>>
>>>>
>>>>
>>>>> Lukas
>>>>>
>>>>> On Sun, Mar 13, 2016 at 12:20 PM, Clark B. Wierda <cbwie...@gmail.com>
>>>>> wrote:
>>>>>   On Sat, Mar 12, 2016 at 5:05 PM, Thomas Wolf <tw...@brocku.ca>
>>>>> wrote:
>>>>> Having AlphaGo playing exclusively on KGS would be such a
>>>>> boost to KGS!
>>>>>
>>>>>   For sure.
>>>>>
>>>>> The other Go servers might have their own opinion on that.
>>>>>
>>>>> Clark
>>>>>
>> ___
>> Computer-go mailing list
>> Computer-go@computer-go.org
>> http://computer-go.org/mailman/listinfo/computer-go
>>
> 
> 
> 
> ___
> Computer-go mailing list
> Computer-go@computer-go.org
> http://computer-go.org/mailman/listinfo/computer-go
> 
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Congratulations to AlphaGo

[Gonçalo Mendes Ferreira]

It does seem unlikely for DeepMind not to move on to "bigger" things,
but maybe the Go community can make some kind of fundraiser to keep an
instance of AlphaGo playing 24/7? I think there are some websites for
this kind of thing. Someone would be in charge of scheduling time for it
to play pros, other programs, and maybe play online on breaks. Just an
idea, oh Google overlords that watch all communications.

Gonçalo

On 13/03/2016 00:06, Lukas van de Wiel wrote:
> Oh, I did not say that it would not be beneficial, to AlphaGo, and to the
> people playing it, and to the Go community as a whole, but still, it will
> have to come from somewhere. Just the electricity bill alone would be
> hair-raising.
> And the big-scale benefits in prestige and marketing are over, with this
> victory.
> 
> It would be cool to build on the works of AlphaGo, and I would like to see
> it as much as the next enthusiast, but I doubt the feasibility...
> 
> On Sun, Mar 13, 2016 at 1:01 PM, Thomas Wolf  wrote:
> 
>>
>>
>> On Sat, 12 Mar 2016, Lukas van de Wiel wrote:
>>
>> And the hardware available for this tournament was tremendous. It remains
>>> to be seen whether the hardware and the people
>>> maintaining it would be available for a longer period. The costs of this
>>> are not to be underestimated. Who would pay it?
>>>
>>
>> The AlphaGo team would get feedback from testing by players with very
>> different ideas/strengths who they would otherwise never get in contact
>> with.
>>
>> For example, Michael Redmond mentioned repeatedly in the last 3 reviews
>> that
>> he would love to play AlphaGo to study Go, to find new openings,...
>>
>>
>>
>>> Lukas
>>>
>>> On Sun, Mar 13, 2016 at 12:20 PM, Clark B. Wierda 
>>> wrote:
>>>   On Sat, Mar 12, 2016 at 5:05 PM, Thomas Wolf 
>>> wrote:
>>> Having AlphaGo playing exclusively on KGS would be such a
>>> boost to KGS!
>>>
>>>   For sure.
>>>
>>> The other Go servers might have their own opinion on that.
>>>
>>> Clark
>>>
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] AlphaGo won first game!

[Gonçalo Mendes Ferreira]

You may also want to check out AGA's commentary by Andrew Jackson and
Myungwan Kim. They don't run out of magnetic stones.

https://www.youtube.com/watch?v=YZPKR7HzM_s

On 09/03/2016 16:13, Richard Lorentz wrote:
> I found Michael Redmond's commentary very good. Helped a weak player
> like me understand what was going on, but occasionally went over my
> head, which I'm sure others appreciated. He came across as a class act.
> 
> His partner, on the other hand, (I forget his name) was more of a
> hindrance to the presentation than anything. Towards the end of the game
> I found him downright annoying.
> 
> -Richard
> 
> 
> 
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Other German poll on Lee Sedol vs AlphaGo

[Gonçalo Mendes Ferreira]

For those who want to try their luck at the nice board, even without
knowing German:

http://www.go-baduk-weiqi.de/gewinnspiel-lee-sedol-gegen-alphago/

-- Gonçalo

On 01/03/2016 01:29, "Ingo Althöfer" wrote:
> Hebsacker-Verlag is the leading German provider of Go equipment.
> They have initiated a poll on the forthcoming man-machine match.
> 
> So far 278 people have voted. The distribution of expected
> scores is:
> 
> Lee Sedol wins by 5-0: 34.2 %
> Lee Sedol wins by 4-1: 29.1 %
> Lee Sedol wins by 3-2: 12.2 %
> total: 75.5 %
> 
> AlphaGo wins by 3-2: 7.2 %
> AlphaGo wins by 4-1: 9.4 %
> AlphaGo wins by 5-0: 7.9 %
> total: 24.5 %
> 
> Amongst those "predicting the correct score" a nice
> go board (valued 380 Euro) is raffled.
> 
> Ingo.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Congratulations to Zen!

[Gonçalo Mendes Ferreira]

In round 26 gnugo vs matilda is this right

"They then disagreed about the status of the black stones at the bottom
of the board (they are dead, but even if they live somehow, White has
still won)."

By my count black has 48 and white 33+7. This caught my eye because
matilda has a pretty good resigning game.

Gonçalo

On 22/02/2016 12:10, Nick Wedd wrote:
> Congratulations to Zen19X, winner of the February KGS tournament!
> 
> My report is at http://www.weddslist.com/kgs/past/120/index.html
>  .
> As usual, I will welcome your comments and corrections.
> 
> Nick
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Frisbee Go

[Gonçalo Mendes Ferreira]

I don't like it very much, simply selecting only from the valid
neighbors would simplify the rules and shorten the game, but I guess
maybe it does seem similar to what would happen in real life. Are there
other games played with frisbees?

Anyways I propose a frisbee-probability GTP command, it is the bare
minimum to play this:

frisbee-probability (optional)
arguments float - Value between 0 and 1
effects   Change the active probability of playing intended
intersection.
outputnone
fails syntax error - fails if out of range probability value (<
0 or > 1); unable to change - fails if invoked in the middle of the game
comments  Programs that only support probability 1.0 should not
include this command in their list_commands output.

Sounds about right? It should be the only change necessary for GTP to
start supporting the frisbee.

Gonçalo




On 21/02/2016 01:18, John Tromp wrote:
> I don't remember if there was consensus, but can repeat my previous thoughts:
> 
>> 1. What happens with plays unintentionally on top of stones or out of
>> bounds?
> 
> Converted to involuntary pass.
> Note that a throw must have some positive probability of converting into
> a legal move. This way, infinitely long games have 0 probability.
> 
>> 1.1 If converted to passes, do they count towards end of play and
>> scoring phase?
> 
> No; only voluntary passes should. Otherwise games would most
> likely end prematurely.
> 
>> 2. How are the play probabilities distributed?
> 
> They're governed by a single parameter, the hit probability p.
> You hit the target with prob. p, and its 4 neighbours with probability 
> (1-p)/4.
> 
> I don't believe there's a single value of p that everyone likes best.
> 
> One extreme p=1 is classical Go. The other extreme p=0 is guaranteed
> to miss the target. Other natural choices are p=1/2 or p=1/5.
> (Values in 1/2 < p < 1 seem a little dull to me).
> 
> regards,
> -John
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

[Computer-go] Frisbee Go

[Gonçalo Mendes Ferreira]

Hello all,

Has a consensus been reached about the rules/GTP modifications for
frisbee Go? I assume a genmove turns into a genmove_reg+play, but:

1. What happens with plays unintentionally on top of stones or out of
bounds?
1.1 If converted to passes, do they count towards end of play and
scoring phase?
2. How are the play probabilities distributed?

I don't remember this being settled, but maybe I've missed it.

Gonçalo


PS: Late congratulations to Silver, Huang et al, and John Tromp.
PPS: My money is still on Lee Sedol.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Computer Go tactics and matrix completion

[Gonçalo Mendes Ferreira]

I haven't read how programs 'catalog' play under various categories, 
like for http://gostyle.j2m.cz/
but only if the acquisition of some features is easier than others, 
giving an incomplete view of the

opponents, would a technique like matrix completion be necessary, no?

If from just 2-5 games we can catalog a player sufficiently well, any 
algorithm for parameter tuning
should suffice for generating a probability distribution of the 
application of different parameter
vectors. Can it be done with just a few games? Probably. Matches are 
long. Probably even changing
parameters automatically midgame would also be possible and be more 
powerful for dealing with

pesky versatile players.

I guess what I'm saying is that to me it is seems overkill for Go 
(besides the whole remembering

every player in KGS thing).

Gonçalo

On 15/01/2016 14:53, "Ingo Althöfer" wrote:

Hello,

the topic "matrix completion" has become famous, in
particular after a competition organized by the
NetFlix company. NetFlix has many customers and (not so)
many films. They want to generate personalized
recommendations for their customers ("you might also like
movie X").

Transfer to the world of go on internet servers:
One problem of go bots against human go players is that
humans learn quickly about special weaknesses of the bot.
Now assume some fictive go bot "Bimbo" with several
secrete parameter settings (S_1, ..., S_m). When a
human plays on KGS against Bimbo he does not know which
parameter set is just activated. The team behind Bimbo
is switching between parameter sets, either randomly or
by some tactics.

What the Bimbo team knows is how well which humans handled
which sets in the past. What they want to find is the
"best" parameter set for the current opponent. Here "best"
is meant with respect to the bot chances. Matrix completion
may help to find "appropriate" settings.

Observe that NetFlix is dealing with thousands of films
and millions of customers. In contrast, on KGS you have
perhaps a few hundred opponents and about a dozen or so
parameter sets. So, "matrix completion" in the Bimbo team
would not be a very hard task.

Ingo.

Wikipedia-Link:
https://en.wikipedia.org/wiki/Matrix_completion

PS. In computer chess, switching secretly between several
program versions was sometimes called "engine revolver".


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

Re: [Computer-go] Board evaluation using a convolutional neural network

[Gonçalo Mendes Ferreira]

Although it cannot replace MC simulations altogether, it *could* be used 
for more accurate prior values I suppose. Do you plan to integrate it in 
a MCTS program and see? Michi is also written in python...


Gonçalo

On 12/01/2016 21:30, Justin .Gilmer wrote:

Hey everyone,
   I recently trained a CNN to do board evaluation in Go. You can see the
work on github:

https://github.com/jmgilmer/GoCNN

The network was trained on 15000 professional games which didn't end in
resignation, I had the network try to predict the final ownership based on
current board position. It's really interesting to see what it learned,
although I'm not sure it would perform well as part of a go engine (it is
not great at life and death). I invite you to check out the github repo, I
have some demonstrations of the model in the README. Any
comments/criticisms/questions are most welcome, I will be working to
improve the model in the future.
Cheers!
-Justin



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

Re: [Computer-go] Go Aesthetics

[Gonçalo Mendes Ferreira]

I agree that playing strength should not be determinant for Go 
aesthetics. Of course obvious mistakes are not pleasant, but I consider 
close matches* with either close styles (symmetry) or very different 
styles more important. Lopsided or early decided matches with big 
captures, handicaps, complicated fights, comebacks, desperate invasions, 
etc are not very pleasing.


Even if it is subjective there must be things like good shape, struggle 
to get sente, fundamentals, etc that most people agree in, even if it 
makes 6d look worse than 2d. (I'm way too weak a player to notice them 
though)


* Not including MCTS programs playing for the 0.5 win.

On 01/12/2016 03:56 PM, Josef Moudrik wrote:

And do you find these "ugly yet working" moves aesthetically pleasing?

I think it all depends what do we mean by aesthetics. In my opinion, it is
not strength - the hard thing about go imo is that while the nice (shape,
..) do often work, sometimes, the ugly move works better - precisely as
Nick writes. It is probably hard to pinpoint; aesthetics could also be
discussed/defined on multiple levels:
  * nice shape moves
  * ease of uderstandability (I find professional games which are simple
aesthetically nicer than wild fights, big tenukis, or "wtf" moments that I
do not understand)
  * interesting strategic developments (e.g. comeback)
  * admiration of player heroism, fighting spirit, ...
All these are subjective points and they probably differ a lot based on the
viewer's own style and (maybe more) strength.

It would be interesting to make a questionnaire to have some base for what
do the players find nice. If we get some questions down, I am willing to
add it to the gostyle site.

Josef

On Tue, Jan 12, 2016 at 4:12 PM Nick Wedd <mapr...@gmail.com> wrote:


On 12 January 2016 at 13:29, Ray Tayek <rta...@ca.rr.com> wrote:


On 1/11/2016 7:10 PM, Gonçalo Mendes Ferreira wrote:

Hi, some time back I mentioned creating a program that evaluates the
aesthetics of a game of Go. Has anyone given it some thought? I'd love to
have a comparison between professional and amateur dan matches,

  ...

shape <http://senseis.xmp.net/?Shape> should be a candidiate. it's
frequency in a game should correspond to rank.



I would be interested to see if this is true.  My own experience suggests
otherwise.  When I watch 3-dan games, and 6-dan games, I think the 6-dans
make more empty triangles. The 3-dans are using shape as a guide (for the
previous moves, as well as the move in question), while the 6-dans don't
use such heuristics, they are able to read the stuff out.

Nick



thanks

--
Honesty is a very expensive gift. So, don't expect it from cheap people - 
Warren Buffetthttp://tayek.com/


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

[Computer-go] Go Aesthetics

[Gonçalo Mendes Ferreira]

Hi, some time back I mentioned creating a program that evaluates the 
aesthetics of a game of Go. Has anyone given it some thought? I'd love 
to have a comparison between professional and amateur dan matches, or 
across time periods or players. There are a few papers on aesthetics for 
chess so I don't see why not Go. It shouldn't be terribly difficult to 
make, after deciding on the things to look for. I'd like to kickstart 
this discussion.


For reference:
Advanced Computer Recognition of Aesthetics in the Game of Chess by 
Azlan Iqbal and Mashkuri Yaacob


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

Re: [Computer-go] The Game AI Forum is back

[Gonçalo Mendes Ferreira]

Hello,

I don't seem able to register an account there. I'm not receiving the
activation e-mail, and I don't have any spam filters. Maybe it's having
problems, or it doesn't contact e-mails with domains other than the most
common hotmails, gmails, yahoos?

Gonçalo

On 01/01/2016 08:56 AM, Rémi Coulom wrote:

Hi,

I had created the Game Programming Forum a few years ago. I decided to
put it online again, at a new URL: http://www.game-ai-forum.org/

Maybe some of you will be interested to participate there.

Rémi

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

[Computer-go] Good Zobrist table for 21x21 and bellow

[Gonçalo Mendes Ferreira]

In attachment I'm sharing a binary file of 882 (21*21*2) 64 bit values 
with perfect bit distribution, for the purpose of being used in Zobrist 
hash tables. Each of the 64 bits appears in 441 values, every 64 bit 
value has 32 active bits and there are no repeated values.


Gonçalo F.


zobrist_table
Description: Binary data
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Standard Computer Go Datasets - Proposal

[Gonçalo Mendes Ferreira]

I think if you start calculating the Zobrist hashes and scraping 
features yourself you will have a neverending variety of datasets.


I would prefer datasets of whole, high quality games without SGF errors, 
perhaps cleaned of identifying information. Parsing an SGF is already 
trivial. I personally divide them in:


- Handicap used or not
- Normal (5.5 - 7.5) or not komi, this disqualifies some older games
- Rules used
- Board size

Following the idea of having more information instead of very specific 
features already extracted, it would be interesting to also have the 
playing times, although I don't know where you'd get that from.


You'd be an angel if you could provide a large dataset of matches with 
Chinese rules, specially in board sizes other than 19x19.


It would of course also have to be completely free for any use. I 
personally only use the KGS 6d+ and a collection of 70k pro games that I 
don't know where it came from. The GoGoD is proprietary. :)


Gonçalo F.

On 11/13/2015 08:39 AM, Josef Moudrik wrote:

Hello List,

There has been some debate in science about making the research more
reproducible and open. Recently, I have been thinking about making a
standard public fixed dataset of Go games, mainly to ease comparison of
different methods, to make results more reproducible and maybe free the
authors of the burden of composing a dataset. I think that the current
practice can be improved a lot.

Since the success of this endeavor crucially depends on how many authors
use the dataset, I would like to ask You (potential authors) a few
questions:

1) Would this be welcomed and used? Would You personally use it? (Am I not
reinventing the wheel?)

2) What parameters should the dataset have? The number of dataset variants
(if any) should be in my opinion kept at bare minimum to reduce
"fragmentation".

2a) Size: My current view is that at least 2 sizes are necessary: small
(1000-2000 games?) and large dataset (5-6 games).
2b) Strength & year span: Currently I am thinking about including modern
professional games only (1970-2015)

3) Do you have any other comments, requirements for the dataset and ideas?


Thanks for Your attention,
Kind regards
Josef Moudrik



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


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

Re: [Computer-go] Standard Computer Go Datasets - Proposal

[Gonçalo Mendes Ferreira]

At least in the past some DCNN made use of the players ranks, so it 
should be best to leave it.


On 11/13/2015 10:27 AM, Josef Moudrik wrote:

On Fri, Nov 13, 2015 at 11:16 AM Erik van der Werf 
wrote:


On Fri, Nov 13, 2015 at 10:46 AM, Darren Cook  wrote:


The advantages of storing games:
   * accountability/traceability
   * for programs who want to learn sequences of moves.



Another advantage of storing games is that it is much more efficient; you
only have to encode one move per position.

Erik



Yes,
I think that having full games would be much more useful. The anonymization
of the I had in mind would include hiding information not important for
computer processing such as file-names, player names, dates, ranks,
comments (given that the dataset would ensure consistent "balanced"
distribution). Like this, the database would have no (or much less) use for
human study.



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


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

Re: [Computer-go] alarming UCT behavior

[Gonçalo Mendes Ferreira]

That doesn't seem very realistic. I'd guess your prior values are 
accurate but the simulations are biased or not representative. Or you 
miss precision in your transition quality floating points. Or there's a 
bug related to being an adversarial problem and you didn't have the 
robots swap colors? :)


Do tell what it was when you discover the problem.

Gonçalo F.

On 06/11/2015 18:48, Dave Dyer wrote:

Developing a UCT robot for a new game, I have encountered a
surprising and alarming behavior:  the longer think time the
robot is given, the worse the results.  That is, the same robot
given 5 seconds per move defeats one give 30 seconds, or 180 seconds.

I'm still investigating, but the proximate cause seems to be
my limit on the size of the UCT tree.   As a memory conservation
measure, I have a hard limit on the size of the stored tree. After
the limit is reached, the robot continues running simulations, refining
the outcomes based on the existing tree and random playouts below
the leaf nodes.

My intuition would be that the search would be less effective in this
mode, but producing worse results (as measured by self-play) is
strongly counter intuitive.

Does it apply to Go?  Maybe not, but it's at least an indicator
that arbitrary decisions that "ought to" be ok can be very bad in
practice.



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

Re: [Computer-go] alarming UCT behavior

[Gonçalo Mendes Ferreira]

That's certainly possible, but assuming the tree is being limited on 
number of nodes, not constant depth, and the selection of equal quality 
candidates to explore is random, how likely is it to happen? The problem 
seems to be constant.


On 06/11/2015 19:29, Marc Landgraf wrote:

It is indeed very realistic and can be recreated in Go.

The issue is, that you are chopping of the tree at a fixed point and this
may heavily bias the the entire tree, if this point influences the playout.
Like imagine there is one big Atari in the entire game, but it can be
easily answered. If you have a single path in your tree that ends with said
Atari, while no other path ends with this Atari played (or the Atari is
already answered in the tree), this path will then dominate all other
pathes, because in this path the likelyhood of winning (by taking the
stones in Atari) is much bigger than in all other branches. But if you
would chop off the last move that branch suddenly the evaluation would be
correct. If you would not do any more playouts on this node, it would be
just one biased playout, not a big deal in the grand scale. If you would
allow the MCTS to continue further, it would also be able to refute the
Atari. But you are stopping right at the atari, and then pile on playouts
that make it seem work.


2015-11-06 19:59 GMT+01:00 Gonçalo Mendes Ferreira <go...@sapo.pt>:


That doesn't seem very realistic. I'd guess your prior values are accurate
but the simulations are biased or not representative. Or you miss precision
in your transition quality floating points. Or there's a bug related to
being an adversarial problem and you didn't have the robots swap colors? :)

Do tell what it was when you discover the problem.

Gonçalo F.


On 06/11/2015 18:48, Dave Dyer wrote:


Developing a UCT robot for a new game, I have encountered a
surprising and alarming behavior:  the longer think time the
robot is given, the worse the results.  That is, the same robot
given 5 seconds per move defeats one give 30 seconds, or 180 seconds.

I'm still investigating, but the proximate cause seems to be
my limit on the size of the UCT tree.   As a memory conservation
measure, I have a hard limit on the size of the stored tree. After
the limit is reached, the robot continues running simulations, refining
the outcomes based on the existing tree and random playouts below
the leaf nodes.

My intuition would be that the search would be less effective in this
mode, but producing worse results (as measured by self-play) is
strongly counter intuitive.

Does it apply to Go?  Maybe not, but it's at least an indicator
that arbitrary decisions that "ought to" be ok can be very bad in
practice.




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

[Computer-go] Not-so-heavy playouts

[Gonçalo Mendes Ferreira]

Hi, does anybody know of a paper or online resource on stochastic heavy 
playouts?


I'm looking for things like the things that should be present besides 
the 3x3 patterns (ladders, nakade), the probabilities of applying each 
pattern type (fleeing atari, capturing, cuts, hane), probabilities of 
choosing a non-matched play based on distance to the previous play, etc. 
I'm using constant probabilities for now.


I'm having difficulties with this (my program is currently much stronger 
with light playouts than with heavy playouts!) - how to produce an 
unbiased heavy playout policy.


Gonçalo F.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Number of 3x3 patterns

[Gonçalo Mendes Ferreira]

If you are considering only black stone, white, empty and border, 
ignoring symmetry, wouldn't it be


3^9 + 3^6 + 3^4

3^9 for patterns away from the border, 3^6 for near the sides and 3^4 
near the corners, assuming you are also interested in the center value.


This makes 20493, then you need to take out illegal patterns (surrounded 
middle stone). So I'd hint it's close to 2.


On 03/11/2015 18:17, Detlef Schmicker wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I could not find the number of 3x3 patterns in Go, if used all symmetrie
s.

Can anybody give me a hint, were to find. Harvesting 4 games I get
1093:)

Thanks, Detlef
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJWOPpEAAoJEInWdHg+Znf45nEP/j4Xy8lJTesaydsiEeuAUZGZ
vfmmOEOYoX6kH2wZ6BA9GqD2NpDlZrm9+DtobTMg3EyrIkIc2kXZVkSm/rS24Jo5
p18Rub2mzeYEw4Qj3/mlr0L4NsO88wNz+vuJdDswr+UqgpEFA8Mqzf8dbC22YegO
HFGOMKPF5BHzl8clZ899N1SUSCRbuZAM/YKmtmJvi56/+MoJCO7gYOWdmUC2KYGu
J72asmmzkGgOZhYPykDF1+nGeed4KiIdtG5b9J0b0/7oV0lu4D36mjhpwbXXA8f3
xCtDO9jm6OG4kIRamCibEmYwVrJFnriltSP5RumyMGYuv7Bv7Ret3+Fgdg7IQFGp
xpH3c4cTE+GJ9d7Afr+FCMJcbEPcYSz+xPDSWhLWfTqYfQj7fh/qepTw2SLs+eD4
bjMWa3dISGnwKhzJykwXUZTqWnL/h3MvXe95Fi8bvYNEMSXCWlG4ajoSDQwwdPT2
Fktv8RJwVmtOYl5EDZhCbXi7zxvTsATyYtAxNbLcGbSyerJVrKh7cFp07GaaKyy/
tbo9tw9AEmb3xZ+qBQNI5lzQqtbWYn3sbu4eLSjIs/njtp2A7cVVW/O1SUrW+wAQ
ePkehsPjQ7yB++op8VZmN/J3f5M2UmO6TgSPDKQNUSeyCeZHzjZDJjH7qoLDr1Mw
fXMMo7Pg5lc6GOOBL885
=LKxP
-END PGP SIGNATURE-
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go


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

Re: [Computer-go] Understanding and implementing RAVE

[Gonçalo Mendes Ferreira]

I think we mean the same. So when black plays at a1 first we count it for
black everywhere but never for white. Correct?
The question is, if both black and white play a1 - because there were 
captures in the middle - whether both of them will update a1 in some of 
their nodes. I believe so.

Ah yes, the UCB term. I’ve now added it. I dimly remember now that Pachi
doesn’t use it but yes I’ve now added it. And I’m not sure I understand you
other comment. My nodes store the visits/etc, the move made, and references
to all children.
I've checked and that's with Pachi/Michi do too. And it's the closest to 
the MCTS diagrams and explanations that are published around. But 
instead you could just have the information on transitions from a state, 
and not wins/visits of the state per se. I'm not very familiar with 
Pachi (I couldn't find how it implements a transpositions table, or how 
it prunes it with memory safety).


I use a structure with
color
visits[19][19]
wins[19][19]
amaf_visits[19][19]
amaf_wins[19][19]
etc

They are very similar, but my node information doesn't need to consult 
the transpositions table or follow points to select the next play. On 
the other hand sequences of play that arrive on the same node have the 
exact same "quality" regardless of sequence of play in Pachi, where in 
my program the sequences of play only "unite" when following that state 
forward.


I don't know if this difference is very small or if I'm forgetting 
something important. Maybe Pachi implements discovering if a state has 
already been expanded in a very efficient way.


I don't know how other programs do it, but instinctively, if you started 
by implementing a non-UCT MCTS algorithm, the information you kept would 
be just the initial state and statistics on the transitions, so my train 
of thought seems (to me) the logical follow up.


Gonçalo F.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Understanding and implementing RAVE

[Gonçalo Mendes Ferreira]

I must admit that I don’t quite follow how you’ve implemented things, but
then you seem to be further along than me as I haven’t even started with
transposition tables.

Urban

Well I took the liberty to steal and very crudely modify a MCTS diagram 
from wikipedia:


http://pwp.net.ipl.pt/alunos.isel/35393/mcts.png

Maybe with images it is clearer. You seem to be using an acyclic graph 
with pointers for the arcs. When you need to find transpositions, and 
free malloc'd nodes because you're out of memory, I find my solution 
much more practical because all the information for selecting what play 
to make is in the current node. But Pachi is no small program so I'm 
sure I'm wrong somewhere.


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

Re: [Computer-go] How to handle triple ko efficiently?

[Gonçalo Mendes Ferreira]

I'm currently using random numbers ensuring they are not 0 or repeated 
in the table, for obvious reasons. I suspect the next step for those 
interested would be ensuring each bit has a similar ratio of 
occurrences, or bruteforcing it.


On 16/10/2015 14:51, Álvaro Begué wrote:

Btw does anyone have a good initialization vector for the Zobrist table?

The obvious thing to try is random numbers. Another idea is turning your
Zobrist key into CRC64, which I think is what you get if you generate your
numbers like this:

#include 

int main() {
   unsigned long long const P = 0x42F0E1EBA9EA3693ull;
   unsigned long long h = P;
   for (int i = 0; i < 1000; ++i) { // Or as many as you need
 std::printf("%016llx\n", h);
 h = (h & 0x8000ull) ? (h << 1) ^ P : (h << 1);
   }
}


Álvaro.


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

Re: [Computer-go] How to handle triple ko efficiently?

[Gonçalo Mendes Ferreira]

Hmmm, that's interesting but for random playouts seems a bit overkill. 
In a random playout kos will only consistently happen if they are the 
last legal positions in the board, at which point it might be better 
just waiting for a few more plays, reaching the max depth and calling 
the score as it is. Testing simple kos should be faster too. Did you 
benchmark the difference between your method and just prohibiting play 
at the last eaten position (if one stone only)? What max depth (if any) 
did you use to limit the playouts?


For hashing I use 64 bit Zobrist hashes of the board contents without 
last  played/eaten information, so it is not changed by passing. On 
collision I memcmp the whole board; if I didn't play legality would be 
off in false eyes, kos, suicides, etc and I store that in the node 
statistics. Btw does anyone have a good initialization vector for the 
Zobrist table?


Gonçalo

On 16/10/2015 13:50, Ben Ellis wrote:

My go playing program mostly just does random play outs so I don't claim to
be an expert, but I check for super KO in my go program and it doesn't seem
to slow it down too much. I use the same algorithm for checking for simple
KO as well.

*This doesn't catch 100% of super KO but it is good enough to prevent
looping in your play-outs.*

 From memory, the high-level algorithm,

At the start of the play out, start with
- HashSet of board hashes
- HashSet of board intersections (pre-populated with all board
intersections)

After each move has been played and captured stones removed,

1. If the played intersection has not been played on before,
 - empty the board hashes set. O(1)

2. If any stones were captured and the intersection has not been played
before,
 - Generate hash O(1)
 - Insert hash into set of board hashes. O(1)

3. If the intersection has been played on before,
- Generate hash O(1)
- Insert hash into set of board hashes and check for duplicate O(1)
- If duplicate, KO or super KO detected O(1)

4. Remove intersection from set of intersections not yet played. O(1)

Conditions at 2 and 3 are infrequent and tend to only happen in the end
game.

Zobrist hash is common I'm not sure of any alternatives.

If you want to check for all moves that would result in a KO or super KO,
you can iterate through all the empty intersections that have already been
played (there usually aren't many unless a big dragon is captured), and see
if they would cause a duplicate hash.

I'm sure someone more academic than me on this list will be able to pick
plenty of holes out of this :)


On 31 August 2015 at 09:18,  wrote:


I once tried to use 32bit hashes only. It might work for super ko
detection, but if you use it for transposition detection storing a lot of
poisitions you will get collisions now and then. So my reasoning is: if 32
bits almost works then using another 32 bits will work.

Best
Magnus


On 2015-08-31 06:26, Minjae Kim wrote:


Is 64 bits really enough?

I may be wrong but there are 3^361 possible board positions in 19x19.
log2(3^361) gives me 572.171..., which means I need at least 573 bits
to record all possible board positions. This still doesn't mean that a
2048 bit Zobrist hash for example will never collide for a 19x19
board, but the odds will be significantly lesser.

Do you have some source about the probability of Zobrist hash
collision on a go board for different bit string sizes?

On Mon, Aug 31, 2015 at 12:37 PM, Peter Drake 
wrote:

64 bits seems to be enough. As I understand it, the convention is to

simply _ignore_ the possibility of collisions; you're more likely to
have a hardware error.

On Sun, Aug 30, 2015 at 8:27 PM, Minjae Kim 
wrote:

To my understanding, you need a sufficiently large bitstring to
minimize possible hash collisions when using Zobrist hashing. When a
hash collision does occur, it can possibly generate an illegal move.
What is an acceptable size of the hash bitstring for a 19x19 board?

On Mon, Aug 31, 2015 at 10:52 AM, Jason House
 wrote:

There are longer cycles that can occur but I have never encountered
any that didn't naturally resolve themselves in the playout.

Zobrist having is cheap to compute (one xor if no stones were
captured). Comparing the resulting number against the others is also
cheap. The hash is also helpful for handling transpositions in the
search tree.

https://en.m.wikipedia.org/wiki/Zobrist_hashing [1]

On Aug 30, 2015 9:17 PM, "Minjae Kim"  wrote:

Yes, but to 'remember' the prior board state, doesn't the program
have to store the whole board position per every turn by whatever
means including Zobrist hashing that you suggested?

After that, the program has to search whether the current position
matches any of the previous ones. You said 3 is enough for triple
kos, but as far as I know aren't there some rare repeating positions
with a cycle longer than 3?

But anyway solving the 

Re: [Computer-go] How to handle triple ko efficiently?

[Gonçalo Mendes Ferreira]

And your method, although I didn't understand it completely, seems very 
similar to having one big hash table with an entry for the Zobrist hash 
of every state of the match, with the advantage of also stopping 
superkos. I used this when I had neural networks playing and they 
absolutely could not fall into a cycle; random playouts shouldn't need this.


On 16/10/2015 13:50, Ben Ellis wrote:

My go playing program mostly just does random play outs so I don't claim to
be an expert, but I check for super KO in my go program and it doesn't seem
to slow it down too much. I use the same algorithm for checking for simple
KO as well.

*This doesn't catch 100% of super KO but it is good enough to prevent
looping in your play-outs.*

 From memory, the high-level algorithm,

At the start of the play out, start with
- HashSet of board hashes
- HashSet of board intersections (pre-populated with all board
intersections)

After each move has been played and captured stones removed,

1. If the played intersection has not been played on before,
 - empty the board hashes set. O(1)

2. If any stones were captured and the intersection has not been played
before,
 - Generate hash O(1)
 - Insert hash into set of board hashes. O(1)

3. If the intersection has been played on before,
- Generate hash O(1)
- Insert hash into set of board hashes and check for duplicate O(1)
- If duplicate, KO or super KO detected O(1)

4. Remove intersection from set of intersections not yet played. O(1)

Conditions at 2 and 3 are infrequent and tend to only happen in the end
game.

Zobrist hash is common I'm not sure of any alternatives.

If you want to check for all moves that would result in a KO or super KO,
you can iterate through all the empty intersections that have already been
played (there usually aren't many unless a big dragon is captured), and see
if they would cause a duplicate hash.

I'm sure someone more academic than me on this list will be able to pick
plenty of holes out of this :)


On 31 August 2015 at 09:18,  wrote:


I once tried to use 32bit hashes only. It might work for super ko
detection, but if you use it for transposition detection storing a lot of
poisitions you will get collisions now and then. So my reasoning is: if 32
bits almost works then using another 32 bits will work.

Best
Magnus


On 2015-08-31 06:26, Minjae Kim wrote:


Is 64 bits really enough?

I may be wrong but there are 3^361 possible board positions in 19x19.
log2(3^361) gives me 572.171..., which means I need at least 573 bits
to record all possible board positions. This still doesn't mean that a
2048 bit Zobrist hash for example will never collide for a 19x19
board, but the odds will be significantly lesser.

Do you have some source about the probability of Zobrist hash
collision on a go board for different bit string sizes?

On Mon, Aug 31, 2015 at 12:37 PM, Peter Drake 
wrote:

64 bits seems to be enough. As I understand it, the convention is to

simply _ignore_ the possibility of collisions; you're more likely to
have a hardware error.

On Sun, Aug 30, 2015 at 8:27 PM, Minjae Kim 
wrote:

To my understanding, you need a sufficiently large bitstring to
minimize possible hash collisions when using Zobrist hashing. When a
hash collision does occur, it can possibly generate an illegal move.
What is an acceptable size of the hash bitstring for a 19x19 board?

On Mon, Aug 31, 2015 at 10:52 AM, Jason House
 wrote:

There are longer cycles that can occur but I have never encountered
any that didn't naturally resolve themselves in the playout.

Zobrist having is cheap to compute (one xor if no stones were
captured). Comparing the resulting number against the others is also
cheap. The hash is also helpful for handling transpositions in the
search tree.

https://en.m.wikipedia.org/wiki/Zobrist_hashing [1]

On Aug 30, 2015 9:17 PM, "Minjae Kim"  wrote:

Yes, but to 'remember' the prior board state, doesn't the program
have to store the whole board position per every turn by whatever
means including Zobrist hashing that you suggested?

After that, the program has to search whether the current position
matches any of the previous ones. You said 3 is enough for triple
kos, but as far as I know aren't there some rare repeating positions
with a cycle longer than 3?

But anyway solving the problem this way seems too expensive to me.
2015. 8. 31. 오전 9:59에 "Jason House"
님이 작성:

Triple ko can be detected by remembering the prior three board
states. A zorbist hash value should be good enough to detect a
repeat.
On Aug 30, 2015 8:46 PM, "Minjae Kim"  wrote:

I finally managed to build a program that can produce a sequence of
random legal go moves. One problem I found recently is that it
rarely never ends a game because of triple ko, especially on small
boards.

One possible solution would be 

Re: [Computer-go] How to handle triple ko efficiently?

[Gonçalo Mendes Ferreira]

Heh you got me there. I guess I do it because there's not really any 
drawback to it, better be safe than sorry, even if only every 10,000 years.


On 16/10/2015 15:21, Álvaro Begué wrote:

That sounds kind of obsessive. I think the probability of having a 0 or
repeated numbers in the table is about 3.18*10^-15 (someone else please
check my math). To generate some intuition for how small this number is, if
you did this a thousand times per second, the expected time to finding a
problematic table is about 10,000 years.

Álvaro.



On Fri, Oct 16, 2015 at 9:59 AM, Gonçalo Mendes Ferreira <go...@sapo.pt>
wrote:


I'm currently using random numbers ensuring they are not 0 or repeated in
the table, for obvious reasons. I suspect the next step for those
interested would be ensuring each bit has a similar ratio of occurrences,
or bruteforcing it.

On 16/10/2015 14:51, Álvaro Begué wrote:


Btw does anyone have a good initialization vector for the Zobrist table?
The obvious thing to try is random numbers. Another idea is turning your
Zobrist key into CRC64, which I think is what you get if you generate your
numbers like this:

#include 

int main() {
unsigned long long const P = 0x42F0E1EBA9EA3693ull;
unsigned long long h = P;
for (int i = 0; i < 1000; ++i) { // Or as many as you need
  std::printf("%016llx\n", h);
  h = (h & 0x8000ull) ? (h << 1) ^ P : (h << 1);
}
}


Álvaro.


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




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


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

Re: [Computer-go] Playout speed... again

[Gonçalo Mendes Ferreira]

Thanks everyone for your responses. This is followup after implementing 
Dusty Leary's  very complete suggestion.


My program is now running 547 playouts/sec and thread, but a lot of 
optimizations were removed so I'm sure there's space for growth here. It 
is now spending 75% of the time in the selection of the play itself by 
probability distribution. The patterns were simplified to not needing 
actual liberty/capture counts.


I'm also considering the whole board for pattern matching only about 1/4 
of the time, like Petr suggested; simplified ko detection, hardcoded 
some patterns, cached all matchable pattern configurations at startup 
(that's 351882 from just 13 base patterns from GNU Go's 
montegnu_classic), etc.


As for more complete heuristics, my UCT search does have itself some 
very heavy heuristics and needs real liberty counts, but I need faster 
playouts before feeling the impact of the UCT states initialization.


Big thanks to Dusty for the structure explanation. I had already thought 
of something similar but never tested it because group captures seemed 
too heavy. I was wrong since the real cost is in testing atari/counting 
liberties.


Thanks again,
Gonçalo

On 15/10/2015 10:30, Petr Baudis wrote:

On Wed, Oct 14, 2015 at 06:00:56PM -0700, Dusty Leary wrote:

The trick to avoid recursively counting liberties:
Track the liberties for a group/chain using a simplified data structure
that looks like struct ChainLibertyInfo { int liberty_count; int
liberty_sum; int liberty_sum_squares; }

The interesting thing about this data structure is that it's a Set which
can answer the isInAtari() query and the getAtariPoint() query, without
having to track a lot of data.  But it doesn't support enumerating all the
liberties.

   This is a nice trick I once implemented too.  But for any kind of
interesting tactical evaluation (which is an important ingredient for
a strong program), you end up needing to be able to enumerate at least
two liberties, ideally even three.  Then, you can't use this trick.


   In Pachi, I got inspired by GNUGo and track liberties only up to
N liberties (N=5 I think).  Any group with more than N is regarded
as having N libs.  This cuts off a lot of overhead, IIRC it helped
me a lot.

   If you are doing probability distribution stuff, I think a popular
trick is first deciding whether you are going to look just in last move
neighborhood or tenuki; most of the time, your roll will go with the
last move neighborhood and you won't need to spend a lot of time going
through the whole board.

   In general, you may simply want to look at how other programs do
things...  There's plenty of fast open source stuff out there.



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

[Computer-go] Playout speed... again

[Gonçalo Mendes Ferreira]

Hi, I've been searching the mailing list archive but can't find an 
answer to this.


What is currently the number of playouts per thread per second that the 
best programs can do, without using the GPU?


I'm getting 2075 in light playouts and just 55 in heavy playouts. My 
heavy playouts use MoGo like patterns and are probability distributed, 
with liberty/capture counts/etc only updated when needed, so it should 
be pretty efficient.


What would be a good ballpark for this?

Thank you,
Gonçalo F.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Playout speed... again

[Gonçalo Mendes Ferreira]

This reply is to both Erik and Petr,

I was running a profile on the program just now. It spends about 90% 
updating information to speed up the playout, these are captures and 
liberties after play and the resulting 3x3 codified part of the board. 
These are updated when needed, so about 4-8 intersections per play on 
average.


In the updating information part, the most costly is a recursive 
function that counts liberties (it spends itself 33% of all time).


It is in C in a modern PC, board size is 19x19. The heavy playout count 
in the meanwhile was raised to 66 per sec/thread. I'm doing a lot of 
optimizing and in the playouts part there is not much I can thin out 
more. With these profiling results I'll attack the liberty counting 
primitives next. You probably know some method more efficient than a 
recursive search over the board surface.


Gonçalo

On 15/10/2015 00:43, Erik van der Werf wrote:

I don't know, what language are you using? Did you do any
optimizations? How many clock cycles does it take your program on
average to make and undo a move (just counting the core board update)?

BTW you didn't specify board size and hardware, so I assumed 19x19 and
a modern PC.

Erik

On Thu, Oct 15, 2015 at 12:56 AM, Gonçalo Mendes Ferreira <go...@sapo.pt> wrote:

Really? I didn't mention it but it's uses MCTS-UCT with RAVE, progressive
pruning, mercy thresholds and max playout depth, etc. What could I be
missing that is that much of a boost in the playouts, in your experience?

Gonçalo


On 14/10/2015 23:40, Erik van der Werf wrote:

You should be able to do at least 50 times faster.

Erik

On Thu, Oct 15, 2015 at 12:27 AM, Gonçalo Mendes Ferreira <go...@sapo.pt>
wrote:

Hi, I've been searching the mailing list archive but can't find an answer
to
this.

What is currently the number of playouts per thread per second that the
best
programs can do, without using the GPU?

I'm getting 2075 in light playouts and just 55 in heavy playouts. My
heavy
playouts use MoGo like patterns and are probability distributed, with
liberty/capture counts/etc only updated when needed, so it should be
pretty
efficient.

What would be a good ballpark for this?

Thank you,
Gonçalo F.


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

Re: [Computer-go] KGS bot tournaments - what are your opinions?

[Gonçalo Mendes Ferreira]

On 10/10/2015 18:30, David Doshay wrote:

I agree completely that there is no way to enforce computational limits over 
the internet.

I am against ‘identical hardware’ tournaments because people have worked to get 
their programs working on the hardware they have, and some people will be on 
the other side of any hardware decision, Mac v.s. PC being the most obvious.

There is no "Mac hardware".


I am left wondering what the point is for such a tournament. Is it to show who 
is the most efficient programmer? Is it to show how these programs might run on 
somebody’s home computer? These things are not important for research code that 
is not intended for resale.
I'm also against identical hardware restrictions, but divisions can be 
very flexible. Not everyone cares for research and you wouldn't be using 
open tournaments for research results either way.


Gonçalo F.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] KGS Tournament Registration

[Gonçalo Mendes Ferreira]

This is what happens when you reuse an e-mail from someone instead of 
writing a new one...


On 10/07/2015 01:40 PM, Gonçalo Mendes Ferreira wrote:

Hi, I'd like to register my program to enter the November computer Go
tournament.

Bot name in KGS: matilda
Bot real name: matilda
Authors: Gonçalo Mendes Ferreira (gonmf at KGS)
Processor power: CPU Intel(R) Core(TM) i7 3930K @ 3.20GHz, RAM: G.Skill
DDR3 4x8GB @ 1.6GHz, doesn't use the GPU

Thank you,
Gonçalo
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

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

[Computer-go] KGS Tournament Registration

[Gonçalo Mendes Ferreira]

Hi, I'd like to register my program to enter the November computer Go 
tournament.


Bot name in KGS: matilda
Bot real name: matilda
Authors: Gonçalo Mendes Ferreira (gonmf at KGS)
Processor power: CPU Intel(R) Core(TM) i7 3930K @ 3.20GHz, RAM: G.Skill 
DDR3 4x8GB @ 1.6GHz, doesn't use the GPU


Thank you,
Gonçalo
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] KGS bot tournaments - what are your opinions?

[Gonçalo Mendes Ferreira]

I think this is a good compromise. Monthly tournaments free for everyone 
and maybe an yearly one segregated by hardware. Having segregated 
monthly tournaments would be a bit taxing on the organization and people 
who would submit their programs for all hardware divisions. Segregation 
based on consumer grade desktops vs others is simple enough.


Since there is no way to confirm the hardware and KGS tournament results 
cannot be used to measure program strength in a reliable way, I'd prefer 
the current theme of casual competitive tournaments.


Gonçalo

On 07/10/2015 15:56, Hideki Kato wrote:

Nick & all,

Another direction for the hardware.  How about introducing two classes
for the Annual Championship?  I.e., no-limit (formula libre) class
and personal computer one.  My proposal for the later is very simple;
one desktop (i.e., non-server) cpu and one video card.

Hideki


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

Re: [Computer-go] KGS bot tournaments - what are your opinions?

[Gonçalo Mendes Ferreira]

I think cluster renting is a little more complex than Rémi makes it 
seem, because behind the few hours of tournament play will be many more 
hours of testing. There are also other reasons why programs may only 
target personal computers, for instance if they're commercial for 
personal use.


If we're thinking of categories, we could adopt an honor system like:
Category A0 - If your computing power is similar to that of a Raspberry Pi
and so on, instead of actually specifying how "computing power" can be 
compared across GPUs/clusters. I'd still prefer very little categories 
(2 or 3) though.



So finally, my actual proposal, is that programs with advanced hardware
configurations handicap themselves.  For example, Zen could unilaterally
announce a lower time limit that it intends to adhere to.


As long as this isn't enforced, I think it's great if a program 
handicaps itself and still wins, it adds excitement to the tournaments.


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

Re: [Computer-go] kgsGtp 3.5.20 has a problem?

[Gonçalo Mendes Ferreira]

It depends on supporting the kgs-chat command I believe. It doesn't need 
to be invoked, just be supported as returned by the list_commands command.


On 10/05/2015 09:10 AM, Rémi Coulom wrote:

Hi Hiroshi,

It is too bad kgsGtp crashed for Aya yesterday. I was using kgsGtp
3.5.20, and did not have this problem. Maybe it depends on the version
of java. I was using default-jre (OpenJDK) in the Ubuntu LTS distro of
Amazon AWS.

Rémi

On 10/05/2015 01:47 AM, Hiroshi Yamashita wrote:

Hi,

Today I lost all games on time in KGS tournament.
Sorry I did not check well.
Today I replaced latest kgsGtp 3.5.20. And looks like
kgsGtp stops after sending "time_left" command.

I found some people have reported this problem.

new kgsGtp client does not work for me, tournament soon
http://computer-go.org/pipermail/computer-go/2014-November/006947.html
http://computer-go.org/pipermail/computer-go/2015-July/007740.html
kgsGTP client
http://computer-go.org/pipermail/computer-go/2015-September/007914.html

kgsGtp 3.5.10 works well.
I put kgsGtp 3.5.10.
http://www.yss-aya.com/kgsGtp-3.5.10.tar.gz

Regards,
Hiroshi Yamashita

-

<--list_commands
-->=--> -->protocol_version
...
-->
<--name
-->=--> -->
<--version
-->=--> -->
<--boardsize 19
-->=--> -->
<--time_settings 2850 0 0
<--boardsize 19
-->=--> -->
<--clear_board
-->=--> -->
<--komi 7.5
-->=--> -->
<--time_settings 2850 0 0
-->=--> -->
<--genmove b
-->=--> -->R17-->
<--time_left b 2699 0
-->=--> -->

java.lang.NullPointerException
   at com.gokgs.client.gtp.y.a(kgsgtp:22)
   at com.gokgs.client.gtp.z.a(kgsgtp:58)
   at org.igoweb.igoweb.client.gtp.aT.a(kgsgtp:107)
   at org.igoweb.igoweb.client.gtp.aM.b(kgsgtp:85)
   at org.igoweb.igoweb.client.gtp.aa.a(kgsgtp:246)
   at org.igoweb.igoweb.client.gtp.c.a(kgsgtp:395)
   at org.igoweb.igoweb.client.gtp.c.a(kgsgtp:378)
   at org.igoweb.igoweb.client.gtp.c.d(kgsgtp:368)
   at org.igoweb.igoweb.client.gtp.ad.a(kgsgtp:164)
   at org.igoweb.igoweb.client.gtp.c.a(kgsgtp:158)
   at org.igoweb.igoweb.client.gtp.al.a(kgsgtp:48)
   at org.igoweb.igoweb.client.gtp.am.a(kgsgtp:431)
   at org.igoweb.igoweb.client.gtp.aq.run(kgsgtp:298)
   at org.igoweb.igoweb.client.gtp.at.a(kgsgtp:18)
   at org.igoweb.igoweb.client.gtp.au.run(kgsgtp:97)
   at java.lang.Thread.run(Unknown Source)




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


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

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

Re: [Computer-go] Computer-go Digest, Vol 69, Issue 2

[Gonçalo Mendes Ferreira]

I actually agree some form of more de facto cooperation could exist. 
Message passing is already used in clusters anyways, some hierarchical 
architecture for Go with different providers could be implemented. There 
are two immediate problems however:


1. Brown said there are some programs that are much better at some tasks 
than others, but I'm not so sure about this and how much stronger would 
be a joint effort to compensate the increase in complexity/comm. 
overhead/etc.
2. To have a joint effort there would have to be a strong financial 
force to pull everyone into the same time table, licensing model, and so 
on. Currently research on computer Go seems to be supported by either 
commercial endeavors or academic research. Even if this did produce a 
stronger player, without a financial force most people would prefer to 
do things their own way, instead of adhering to the Go juggernaut. It 
would become an effort of just a few "computer Go experts".


The more I think about it the more the word "MoGo" comes to mind.

Gonçalo F.

On 02/10/2015 19:26, Petri Pitkanen wrote:

I think very few people here do not know message passing style of
programming.  I just not suited problem at hand. Not very cPU efficient.
This is high speed simulation anyways



2015-10-02 16:53 GMT+03:00 djhbrown . :


.
"sharing code is typically not going to be practical."

that's not what i suggested.  perhaps someone else can explain the concept
of message-passing distributed architecture better than me


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

Re: [Computer-go] modus operandi

[Gonçalo Mendes Ferreira]

Maybe someone in need of ideas for MSc/PhDs, or a taste for social 
activism will pick up that idea.


Yes, you, if you're reading this, you can become the next Stallman.

Just imagine the amount of resources (read: money) that would pour in if 
people were convinced of a Russia+China vs The World war by proxy 
competition on computer Go.


On 03/10/2015 00:00, djhbrown . wrote:

"To have a joint effort there would have to be a strong financial force to
pull everyone into the same time table, licensing model, and so on".

Money does make the world go around. Anthropologists and sociologists and
investigative journalists have revealed that throughout the history of
mankind,  the profit motive of unscrupulous goldfingers has exacerbated the
scale of conflicts, turning what had evolved within the human genome as
mate-competition aggression into broadscale rabid genocidal megalomania.
However, there is another side to the human psyche's motivation apparatus,
namely that of socialisation.

Rome wasn't built in a day, and although it was, like the pyramids, largely
built with slave and/or indentured labour, it was built by more than one
egocentric old man determined to prove to himself that he is better than
his Dad, or better than he thought his Dad thought he was.

There are examples of non-profit collaborations such as Gnu, Creative
Commons, and the Open CourseWare initiative.  Although the latter is mainly
a marketing channel, it also distributes information freely; one of very
few examples of the trickle-down effect actually happening.

So no, there doesn't have to be a strong financial force, merely a strong
sociality one, or at least a recognition that many hands make light work
and a willingness the share the glory.

MCTS seems to be very good at small-scale fighting, whereas CNN might be
better-suited to fuseki.  I'm sure it hasn't escaped your notice that 19x19
is 4 times 9x9, but borders of teacups overlap, so a flitting-around fovea
is needed rather than a stationary one, and that requires a CEO to tell it
where to flit.  Or, rather, to tell them where to flit, if there were an
internetworked army of foveas, each doing his own local reconnaisance and
reporting back to HQ.

That CEO, like all CEOs, can make the big decisions, but having a head no
smarter than a toilet-cleaner's or rice-paddy plougher's, it can only do so
much, so it needs to be supported by a cabinet of consultants, each of whom
has its own set of information filters and labour force, to offer the CEO a
small set (7 plus or minus 2) of simple choices.  In the real world, the
Sir Humphreys always ensure that their Minister makes the choice they want
him to make, but in the mind of a machine, rational objective globally
beneficial decisions are theoretically possible.

This message is only for those who haven't lost the idealism of youth, as
old dogs don't like new tricks and more often than not would would rather
shoot the messenger than contemplate the message.  It might happen in
academia, if ITers ever learn to follow the example of their medical
colleagues, whose lists of authors are usually longer than the substantive
content of their papers.

How could it happen?  Don't ask me - i'm a Steppenwolf.  Besides, i am far
too busy with much more important things like smelling roses, so i don't
have the time.


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

Re: [Computer-go] How to only play games with correct handicap on KGS?

[Gonçalo Mendes Ferreira]

I'm not sure but try removing the free handicap placement commands from 
the list of supported commands, returned by the command list_commands. 
The commands should be set_free_handicap and place_free_handicap.


The documentation on kgsGTP reads "If your engine does not support these 
commands then handicap games will be refused.".


Gonçalo F.

On 01/10/2015 16:58, Martin Mueller wrote:

I have a new version of Fuego playing on KGS as ranked robot fuego19. I would 
like people to play with correct handicap to get a more reliable rating. Is 
there a way to do this with kgsgtp?

Thanks

Martin

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


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

Re: [Computer-go] impact of AI on Go ... Where / How do i start ?

[Gonçalo Mendes Ferreira]

Well, I'd argue there is nothing inherently superior about copying the 
human natural processes, instead of using our intellect to find a way to 
achieve better results in simpler ways. Humans were also not born with 
domain over tools, or fire, do you suppose there are two kinds of 
people, the curious and the ones that didn't go extinct?


Of course knowing about ourselves is interesting by itself, but I think 
we have already a good idea of how our brains work (at least while 
playing Go), and for practical reasons those same processes are just not 
as feasible to apply with the tools we have.


If you are writing a Go program that attempts to be competitive, then it 
will be judged based on that. It doesn't make sense to complain that 
people are not writing competitive programs using techniques that showed 
poor returns in the past.


Gonçalo F.

As a sidenote, I'd be very much interested in a Go program that 
attempted to evaluate Go aesthetics, like Chesthetica did for western chess.


On 09/27/2015 10:11 AM, djhbrown . wrote:

it rather depends on what you think AI is all about and what you want to
achieve.

there are two kinds of people in the world: those who are curious, and
those who just want to make yet another cloned ticky-tacky mousetrap so
they can compete on the Go playing-field because they're no good at
football or kung-fu or [rest left unsaid].

If you want to write a go-playing program in a hurry, don't waste your time
talking to me; just do what most others do and just follow/copy Mogo/Crazy
Stone, possibly adding a tweak or two of your own, and stick your "look ma,
no hands" robot on a server with all the others.

If instead you would like to participate in a project to build a Go program
that uses hierarchical planning and reasoning, you can talk to me.  You
could start by googling me and reading my papers and the papers of others
that reference mine.  And the ones that don't.  Start with De Groot's
seminal book entitled "Thought and Choice in Chess".  Then read everything
Herbert Simon has ever written.  And Minsky, and and and.

Please be aware that i envisage it would take dozens of programmers dozens
of years for what i have in mind to get anywhere.  At 66, i won't live long
enough to see it happen.  And even after all that effort, although a
program can be written that would be able to tell you what it is thinking
in a way that makes sense to people, it probably wouldn't perform at shodan
level, let alone be as strong as Zen19, let alone a future "Son of Big Blue
+ Watson", which would probably use simple pattern-matching database search
+ MCTS blind random search and/or CNN or, more likely, a novel
variant/synthesis of them on a massively parallel computer.  Zen19's
authors tell me it improved its performance an entire rank by shifting from
a single processor to 4 processors on a 1Gb Ethernet.  Watson has about
30,000 processors on a 100Gb Ethernet i think.

Whichever route you try, you are unlikely to get anywhere non-trivial doing
it on your own, unless you are a Mozart of the keyboard and had produced
impressive programs by the age of 8 years old.  After you reach the ripe
old age of 19, your brain basically stops growing except for a few neurons
in your neocortex to stop you doing thoughtless teenage things; apart from
that, your learning curve is downhill from then on...

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

Re: [Computer-go] copying the human natural processes

[Gonçalo Mendes Ferreira]

Well I'll just point out a few things...

>That is not to say that AI cannot learn a great deal from cognitive 
psychology etc, but you are welcome to ignore basic research.
I never said otherwise. Likewise you are welcome to ignore research in 
computer Go.


>then you know more than Christoph Koch, because he knows that he 
doesn't yet have a good idea about how brains work, which is why 
studying the brain is his life's work.
I said while playing Go, which you conveniently ignored. I also meant 
having a sensible idea of what is happening, not full mastery on the 
subject. Knowledge enough to play Go, if I wasn't explicit enough.


>i think that when you say "you" you mean yourself and David Fotland 
who repeatedly has expressed the same view as you. I am not.

1. I appreciate being put into the same bag as mr Fotland.
2. By "you" I meant the hypothetical average person interested in 
computer Go, such as Cai Gengyang. Competitive results are also a simple 
metric for Go players, whereas your ideas of understanding of the game 
are not so easily formulated.


Your aggressiveness against a MCTS approach is just not what I thought 
was right for someone asking about computer Go.
You also seem to romanticize a world where MCTS is fully understood and 
set in stone, with other approaches never before tried, victims of some 
conspiracy of probabilistic zealots.


>i give up. masochism is not my bag. i pointed to the water, but you 
and just about everyone else with a mouse in their hands obviously 
prefer canned fizzy drinks instead.
I agree arguing about this is not a good time investment. I'm sure 
there's room for research in whatever application of AI a newcomer to 
computer Go might be interested in.


Gonçalo F.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Building a Go AI Machine

[Gonçalo Mendes Ferreira]

http://senseis.xmp.net/?ComputerGo

On 26/09/2015 16:23, Cai Gengyang wrote:

Hello Computer-Go members,


So I am back and ready to get started with building a Go AI Machine. I am
genuinely quite intrigued by the potential impact of AI on Go and also
other applications ... Where / How do i start learning how to build this?


Thanks a lot !

Gengyang


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

[Computer-go] kgsGTP client

[Gonçalo Mendes Ferreira]

This is frustrating. Since version 3.5.20 of the KGS kgsGTP program is 
still broken on the kgs-chat command, can anyone send me a copy of a 
previous version? The KGS website doesn't offer previous releases.


Something newer than 3.3.9 at least please.


Gonçalo F.

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

Re: [Computer-go] Neural Network Chess Computer Abandons Brute Force For "Human" Approach

[Gonçalo Mendes Ferreira]

I haven't opened the links but my immediate 2 cents are:
1. chess master level is not impressive for a chess engine
2. trained ANN have diminishing returns of their error curves, so saying 
it "only" took three days is not a good indicator of anything
3. from the domain name and bold claims I suppose it must be a 
sensationalist news website


Gonçalo F.

On 09/15/2015 01:58 AM, Ray Tayek wrote:

http://games.slashdot.org/story/15/09/14/219/neural-network-chess-computer-abandons-brute-force-for-human-approach


Posted by samzenpus  on Monday September
14, 2015 @06:53PM from the
how-about-a-nice-game-of-global-thermonuclear-war dept.

An anonymous reader writes: /A new chess AI utilizes a neural network to
approach the millions of possible moves in the game without just
throwing compute cycles  at the problem
the way that most chess engines have done since Von Neumann. 'Giraffe'
returns to the practical problems which defeated chess researchers who
tried to create less 'systematic' opponents in the mid-1990s, and came
up against the (still present) issues of latency and branch resolution
in search. Invented by an MSc student at Imperial College London,
Giraffe taught itself chess and reached FIDE International Master level

on a modern mainstream PC within three days./



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


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

Re: [Computer-go] Neural Network Chess Computer Abandons Brute Force For "Human" Approach

[Gonçalo Mendes Ferreira]

I've heard about that. Maybe it's because of AMAF statistics being less 
useful in chess? I know nothing of chess AI beyond minimax pruning.


On 09/15/2015 04:10 AM, Igor Polyakov wrote:

afaik monte carlo approaches in chess achieved less than 1000 FIDE level

On 2015-09-14 20:09, Gonçalo Mendes Ferreira wrote:

I haven't opened the links but my immediate 2 cents are:
1. chess master level is not impressive for a chess engine
2. trained ANN have diminishing returns of their error curves, so
saying it "only" took three days is not a good indicator of anything
3. from the domain name and bold claims I suppose it must be a
sensationalist news website

Gonçalo F.

On 09/15/2015 01:58 AM, Ray Tayek wrote:

http://games.slashdot.org/story/15/09/14/219/neural-network-chess-computer-abandons-brute-force-for-human-approach



Posted by samzenpus <mailto:samzen...@slashdot.org> on Monday September
14, 2015 @06:53PM from the
how-about-a-nice-game-of-global-thermonuclear-war dept.

An anonymous reader writes: /A new chess AI utilizes a neural network to
approach the millions of possible moves in the game without just
throwing compute cycles <http://arxiv.org/abs/1509.01549> at the problem
the way that most chess engines have done since Von Neumann. 'Giraffe'
returns to the practical problems which defeated chess researchers who
tried to create less 'systematic' opponents in the mid-1990s, and came
up against the (still present) issues of latency and branch resolution
in search. Invented by an MSc student at Imperial College London,
Giraffe taught itself chess and reached FIDE International Master level
<https://thestack.com/iot/2015/09/14/neural-network-chess-computer-abandons-brute-force-for-selective-human-approach/>

on a modern mainstream PC within three days./

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

Re: [Computer-go] Go in virtual reality

[Gonçalo Mendes Ferreira]

First implement a small bot that plays legal moves including detecting 
superkos.


Then read Bensons definition of unconditional life, the Tromp-Taylor 
rules and the GTP standard draft.


On 09/07/2015 10:00 PM, Sébastien 'Cb' Kuntz wrote:

Hi list,
I'm working on a small immersive VR Go application (Oculus, HTC Vive etc)

My goals are:
- play remotely against somebody else in VR
- play remotely against somebody on IGS
(- try to get better at Go)

Since I'm only a beginner in Go,
I'm looking for the minimal set of functions that I need to implement in
order
to be able to play full games.

Currently implemented:
- 19x19 board
- Place a black or white stone anywhere
- Can't play if not your turn
- Can't play if move is not legal (suicide or ko)
- Captured stones disappear from board
- Captured stones count
- Score estimation
- IGS: login, challenge a user, play move, receive move

Planned:
- Pass
- Resign
- Undo
- Save to SGF
- Handicap

Maybe:
- 9x9
- 13x13

I am most probably missing some functions to complete the minimal set,
so any comment is greatly appreciated :)
Have a great day!
cb


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

Re: [Computer-go] gtp question - can black make 2 moves in a row.

[Gonçalo Mendes Ferreira]

That is clearly stated in the GTP but should also depend on the program.

There are improvements a computer Go program can make assuming it is 
playing only as one of the players, such as cleaning states from a 
transpositions table that cannot be reached anymore. I'd assume if you 
want to benchmark something it would be better to only have each GTP 
player play one of the colors, unless the authors of said program 
explicitly say it doesn't matter.


On 09/06/2015 08:22 AM, Ray Tayek wrote:

On 9/6/2015 12:03 AM, Hellwig Geisse wrote:

On Sa, 2015-09-05 at 23:51 -0700, Ray Tayek wrote:

i am guessing that the client should make the moves if he gets them.

does anyone know for sure?

 From the GTP specification, page 18, 6.3.3 Core Play Commands:

"play:
[...]
Consecutive moves of the same color are not considered illegal
from the protocol point of view.


thanks for the confirmation.



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

Re: [Computer-go] gtp question - can black make 2 moves in a row.

[Gonçalo Mendes Ferreira]

Scratch that I misread.

On 09/06/2015 11:28 AM, Gonçalo Mendes Ferreira wrote:

That is clearly stated in the GTP but should also depend on the program.

There are improvements a computer Go program can make assuming it is 
playing only as one of the players, such as cleaning states from a 
transpositions table that cannot be reached anymore. I'd assume if you 
want to benchmark something it would be better to only have each GTP 
player play one of the colors, unless the authors of said program 
explicitly say it doesn't matter.


On 09/06/2015 08:22 AM, Ray Tayek wrote:

On 9/6/2015 12:03 AM, Hellwig Geisse wrote:

On Sa, 2015-09-05 at 23:51 -0700, Ray Tayek wrote:

i am guessing that the client should make the moves if he gets them.

does anyone know for sure?

 From the GTP specification, page 18, 6.3.3 Core Play Commands:

"play:
[...]
Consecutive moves of the same color are not considered illegal
from the protocol point of view.


thanks for the confirmation.


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

Re: [Computer-go] re Mental Imagery

[Gonçalo Mendes Ferreira]

(Hello, I'm new to this mailing list)

Some of the things you say remind me of Mentifex style AI ramblings, but 
again, I did enjoy what I watched of the videos, so it's at least 
entertaining in a weird way even if it doesn't produce any breakthrough 
in computer Go.


Try mixing some weird music and making longer videos, I'd like to have 
longer moments of trance.


On 04/09/2015 13:29, djhbrown . wrote:


Many Faces of Go gives reasons for its moves after fact.  It
reasons about the position using go proverbs, life and death
analysis, group strength and connection information, etc.  If you
have a copy, you can ask it to explain its reasons for making a move.


Many Faces of Go is a proprietary program; is there a description of 
how it works and/or some samples of its type of explanation in the 
academic literature or elsewhere in the public domain?


This approach has been explored thoroughly and it doesn’t work.


I will address this issue in a future video.

Do have a plan to write some code or this just philosophy?


i am starting out on step 1 of an iterative design process and posting 
to this forum in the hope of exchanging scientific/engineering ideas.  
i started programming in 1965;  on finishing my PhD on machine 
learning in 1975, i was happy to thereafter leave the taxing work of 
producing code to younger and more energetic minds.



For this to work, group strength and connection status must be a)
assessed meaningfully and b) applied meaningfully within a broader
conceptual framework.


agreed

What were your definitions for group strength and connection
status, for what purposes did you use them and how did you apply them?


Many years ago, John McCarthy (who coined the phrase "Artificial 
Intelligence") complained that there were too many AI papers of the 
"look, Ma, no hands!" type.  He is one of my gurus, and i agree with 
him.  i am not presenting a "fait accompli"; i am starting out on step 
1 of an iterative design process and posting to this forum in the hope 
of exchanging scientific/engineering ideas.


my videos are intended to be thought-provoking to a general audience
​ ,​
  to interest newcomers in Go
​ , and to prompt an exchange of ideas on software representation models​
; if they fail to
​ catch your imagination, please do not watch them and ignore my 
postings.  if you wish me to be excised from this listserv, you can 
petition its moderator.


i asked three strong players to glance at "what do you see?" for a 
couple of seconds and share their thoughts on what they saw with me; i 
had thought it was a simple situation to use as an initial experiment 
but was surprised to find that they had three different views of the 
position and three different forecasts (dead, probably ko, and seki).  
it would be interesting to see what a strong program makes of it. 
given that it is less than 9x9 in scope, i would expect a Monte-Carlo 
player to be able to find a good solution.  if more than one program 
owner tries it, they could compare notes.











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


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

[Computer-go] Dynamic komi - VBSC

[Gonçalo Mendes Ferreira]

I've been wrapping my head about dynamic komi adjustments for MCTS, 
namely on the thesis by the Pachi creator, Petr Baudic.


On value-based situational compensation the author uses the average on 
win rates from the previous simulations to decide whether or not to 
change the komi. But I don't see how this criteria makes sense, if we're 
interested in finding the best play, shouldn't we be trying to have good 
sensibility around the best plays? Trying to average the game only 
worsens the ability of the search to differentiate the best contenders.


Am I seeing this wrong? Has this been addressed before? What do other 
engines do?


- Gonçalo F.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Dynamic komi - VBSC

[Gonçalo Mendes Ferreira]

On 04/09/2015 16:29, Stefan Kaitschick wrote:
The best contenders may be best for entirely different reasons. How do 
you compare a line that tries to bring down a huge group with a line 
that cautiously tries to optimize safe points. It's really hard to do.

That's for the search policy to decide in the end.
And whereever the dynamic komi lands, pedestrian variations may look 
great or totally uninteresting. The idea of dynamic komi is to give 
enterprising variations short of kamikaze a chance of prevailing in 
poor positions, and humdrum variations better than passing a chance in 
comfortable positions.
If I'm understanding correctly then I'd like to move the best plays 
closer to 50% winrate, in situations where there are a few plays with 
100% winrate and the rest are terrible. In lopsided cases like this 
moving to the average is actually making more plays with 100% winrate, 
which is not helpful, right?


I agree that, of course some not great but promising plays suffer if we 
use the highest win rate, but if the threshold to change the komi is 
something like 70%-90% I don't think that's our main concern anymore.


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

Re: [Computer-go] re comments on Life and Death

[Gonçalo Mendes Ferreira]

Convolution neural networks seem to be all the rave (no pun intended) 
right now. To me they do seem more intuitive in recreating the process 
of a human being recognizing patterns and getting a general feel of the 
game, and then focusing on only a few sequences. Maybe they are limited 
by the data set, but so is a human being limited by his/her own 
experience, so I definitely see space to grow there.


At least one paper from 2014 already used a convolution neural network 
in some form of selection guiding policy of new MCTS tree nodes, with 
promising results. I'm currently also researching something similar.


On 04/09/2015 23:52, uurtamo . wrote:


Learned rules from pure stats might be good guiding posts, but the 
pure checking of millions of board positions is always going to be 
necessary.


My $0.02,

s.

On Sep 4, 2015 3:49 PM, "Jim O'Flaherty" > wrote:


I disagree with the assertion MC must be the starting point. It
appears to have stagnated into a local optima; i.e. it's going to
take something different to dislodge MC, just like it took MC to
dislodge the traditional approaches preceding MC's introduction a
decade ago. Ultimately, I think it can serve to inform a higher
level conceptual system

And while I don't get his videos (they are way to ADHD scattered
and discontinuous for my personal ability to focus and
internalize), I think I grok the general direction he'd like to
see things head. And I am quite ambivalent about the idea of
creating and using linguistic semantic trees as an approach, as
much or even more than I was about MC when it emerged.

On Fri, Sep 4, 2015 at 10:55 AM, Stefan Kaitschick
> wrote:

So far I have not criticised but asked questions. I am a great
fan of the expert system approach because a) I have studied go
knowledge a lot and see, in principle, light at the end of the
tunnel, b) I think that "MC + expert system" or "only expert
system" can be better than MC if the expert system is well
designed, c) an expert system can, in principle, provide more
meaningful insight for us human duffers than an MC because the
expert system can express itself in terms of reasoning.
(Disclaimer: There is a good chance that I will criticise
anybody presenting his definitions for use in an expert
system. But who does not dare to be criticised does not learn!)

MC is currently stagnating, so looking at new (or old
discarded) approaches has become more attractive again.
But I don't think that a "classic" rules based system will be
of much use from here. It is just too far removed from MC
concepts to be productively integrated into an MC system. And
no matter what, MC has to be the starting point, because it is
so much more effective than anything else that has been
tried.What you are left to work with, is the trail of
statistics that MC leaves behind. That is the only tunnel with
a possible end to it that I see. And who knows, maybe someone
will find statistical properties that can be usefully mapped
back to human concepts of go.



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