Re: [Computer-go] Frisbee Go Simulation

2015-11-21 Thread robertfinkng...@o2.co.uk

Hi Ingo,

Thanks, yes I see it is good to keep it simple to begin with, not least, 
to encourage entrants that it is not a big hurdle.


Due to the lack of definite answer to "what epsilon?" the core idea was 
simply that if you keep epsilon small, then the restriction you made 
about only displacing by one, and no diagonal displacement, would not be 
inconsistent with the real world. On the other hand, a large epsilon 
would be an immediate deviation from real frisbee go (given the 
displacement restriction). Also, I suspect that if epsilon is large the 
skill in the game will be much lower than if it is zero, but somewhere 
inbetween, maybe there will be an epsilon that requires more skill than 
either extreme. It am a fairly weak player, but it seems to me that the 
tactical side of the game is vital and would easily be lost.  I can see 
that if the tournament is 9x9,0.017 does seem too small; having only a 
75% chance of a miss once per game may be a bit pointless!


Anyway, it was just a thought. It's great to see that David has a 
version of Many Faces that will play - all the best with the tournament.


Regards

Raffles

On 19-Nov-15 13:25, "Ingo Althöfer" wrote:

Hello Raffles,
  

... Since this is based on a real world variant of Go, why not base epsilon on 
that? ...


In "true Frisbee Go" many more aspects may be taken into account:

* During the first moves one may learn how good the throwing skills of the 
opponent are...

* weather (and wind) may play a role in outdoor play

* a player may deliberately throw weakly in the beginning to
lead the opponent to wrong conclusions

* players may be allowed to use "moving robots" who can
change the place from where they throw

...

The Frisbee Go Simulation is meant to leave all these
sophistications outside (at least in 2016).

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

-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7227 / Virus Database: 4460/11042 - Release Date: 11/21/15


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

Re: [Computer-go] Frisbee Go Simulation

2015-11-13 Thread robertfinkng...@o2.co.uk

  
  
If this catches on, perhaps the rules will be referred to as the
  Ingo rules ;-)
  
  Since this is based on a real world variant of Go, why not base
  epsilon on that? The fact that the limit of displacement from the
  intended position is limited to the immediately adjacent points,
  suggests that the thrower is pretty accurate. The distribution is
  narrow enough that the chance of going further afield is
  (effectively) zero. Therefore epsilon should be pretty tiny. It
  must be large enough that there is a chance of the frisbee being
  at least 50% over the line (i.e. epsilon > 0), but small enough
  that the chance of it going 70.7% over the line is vanishingly
  small (otherwise we would be allowing it to be displaced onto the
  diagonally adjacent positions).
  
  Assuming a Gaussian distribution (probably not true for frisbees
  but it will do) and assuming 3 standard deviations away is close
  enough to "vanishingly small", we have 3.sigma = 0.7071...
  (sqrt(0.5)), sigma = 0.2357 (sqrt(0.5)/3), tipping point for throw
  being >50% over the line t.sigma = 0.5, t = 0.5 / sigma =
  3.sqrt(0.5) = 2.12 => epsilon = 0.017, approximately 1 in 60.
  
  Looking at this from a purely combinatorial point of view,t we
  need 1/epsilon > number-of-moves-in-a-game but 1/epsilon^2
  << number-of-moves-in-a-game, which 0.017 seems to satisfy
  for all common board sizes.
  
  Hopefully such a small epsilon also avoids destroying the
  possibility of local tactical play but also introduces a new
  element to the game (75% chance of at least once displaced move in
  81 move game, over 99% chance of at least one displaced move in a
  361 move game).
  
  In fact to model the real world, epsilon ought to vary depending
  on the move. It should increase depending on distance from
  throwing position, and should not be equal for N,S,E and W
  displacement. Assuming standing south of the board, we expect
  epsilon N > S > E = W (range is normally harder to judge
  than direction and overthrows tend to be worse than under-throws).
  
  It seems to me this may bring in interesting elements to move
  choice - it may be better to play a weaker move which is closer
  and therefore more likely to be played successfully than a
  stronger move which is less likely to be played successfully.
  
  But perhaps this over complicates things - how does it work out
  with fixed epsilon around 0.017.
  
  Raffles
  

On 11-Nov-15 15:29, Álvaro Begué wrote:


  1/5 also seems natural (equal chance of hitting
each the 5 possible points).

Álvaro.


  
  
On Wed, Nov 11, 2015 at 10:08 AM, John
  Tromp 
  wrote:
  > By the way: It would also be necessary to
  decide about
  > the eps for the event. Natural candidates would be
  > eps=0.1 or eps=0.125.
  
I would say the 2 most interesting choices are 1/8 or
1/4.
The latter guarantees you miss your aim by distance 1,
while the former gives you an even chance to hit it.

-John
  

  ___
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
  
  
  
  No virus
found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7163 / Virus Database: 4457/10958 - Release
Date: 11/06/15


  

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

Re: [Computer-go] AMAF/RAVE + heavy playouts - is it save?

2015-11-03 Thread robertfinkng...@o2.co.uk

  
  
You have to be careful what heuristics you apply. This was a
  surprising result: using a playout policy which in itself is a
  stronger go player can actually make MCTS/AMAF weaker. The reason
  is that MCTS depends entirely on accurate estimations of the value
  of each position in the tree. Any playout policy which introduces
  a bias therefore weakens MCTS. It may increase precision (lower
  standard deviation) but gives a less accurate assessment of the
  value (an incorrect mean). Most playouts at the moment (at least
  published ones) are based on Remi's Mogo playout policy, which
  increases precision without sacrificing accuracy.
  
  There's a really nice diagram in one of David Silver's papers
  illustrating the effect that bias can have on playouts. As soon as
  you see it you understand the problem. Unfortunately I don't have
  it to hand and have unfortunately run out of time looking for it,
  otherwise I'd reference it. Hopefully somebody else can give the
  reference. I suspect David probably co-authored the paper in which
  case apologies to the other author for not crediting them here!
  
  I hope this helps
  
  Regards
  
  Raffles

On 03-Nov-15 19:38, Tobias Pfeiffer
  wrote:


  Hi everyone,

I haven't yet caught up on most recent go papers. If what I ask is
answered in one of these, please point there.

It seems everyone is using quite heavy playouts these days (nxn
patterns, atari escapes, opening libraris, lots of stuff that I don't
know yet, ...) - my question is how does that mix with AMAF/RAVE? I
remember from the early papers, that they said it'd be dangerous to do
it with non random playouts and that they shouldn't have too much logic.

Which, well, makes sense (to me) because the argument is that we play
random moves so they are order independent. With patterns that doesn't
hold true anymore.

What's the experience out there? Does it just still work? Does it not
matter because you just "warm up" the tree? Or do you need to be careful
with what heuristics you apply not too break RAVE/AMAF?

Thank you!
Tobi


  
  
  
  ___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
  
  
  
  -
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7163 / Virus Database: 4457/10906 - Release Date: 10/28/15



  

___
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

2015-09-26 Thread robertfinkng...@o2.co.uk

One list of go specific papers can be found here:

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

Of course you will also need tools for writing software.


On 26-Sep-15 16:24, Gonçalo Mendes Ferreira wrote:

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

-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6140 / Virus Database: 4419/10706 - Release Date: 
09/26/15


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

Re: [Computer-go] Building A Computer Go AI

2015-08-21 Thread robertfinkng...@o2.co.uk

Hi,

Good news. There are a variety of open source projects out there, 
including both complete programs (Fuego, Pachi) as well as libraries to 
build your own Go engine (libEgo). There are also a wealth of papers 
explaining the theory behind the top algorithms. Try googling AMAF 
algorithm or RAVE algorithm or MCTS algorithm or TD Search 
algorithm as a starting point. There is a nice Thesis on Pachi too 
google Pachi Thesis.


I hope this helps :-)

Regards

Raffles

On 21-Aug-15 8:48, CaiGengYang wrote:

Hello …


I am a 3d~~5d go player from Singapore.

Keen to learn how to build a powerful Computer Go AI to compete in the Computer 
Go Tournament and also for admissions to a Computer Science college program.

Have very little programming experience except following some code examples on 
CodeAcademy … how do I start building a Computer Go AI ?


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

-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6125 / Virus Database: 4392/10476 - Release Date: 08/21/15


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

Re: [Computer-go] Cogito--another minimal Go engine

2015-03-27 Thread robertfinkng...@o2.co.uk
I suspect some people may not be curious enough to follow the link, but 
may be intrigued if they saw the code...


#define S W*W
#define A B.s[1]-B.s[2]-K
#define F(x,l)for(x=0; xl; x++)
#define P F(x,4)
#define Q(n)P z(~(s=n[x]))
#define R while
#define r return
#define z if
#define C int
#define L struct
L N{ C i,g; float w; L N*h,*s; } O[G*W];
L{ L{ C h[4],p,l; } M[S]; C b[S],c,u[S],i[S],I,p,J,s[3]; } B,F; g; Z; m; 
i; e[S][4]; a[S][4]; E; J=2;

char T[9]; long long t,Q[4096],_,v=k,q;
#define M B.M
#define b B.b
#define c B.c
#define u B.u
#define I B.I
p(i){ r~M[i].p?p(M[i].p):i; } X(i){ C x,s; B.s[b[i]]--; 
Q(e[i])b[s]M[p(s)].l++; P M[i].h[x]=M[i].p=-1;

b[u[B.i[i]=I++]=i]=0; } y(i){ C x,s; z(b[i]){ Q(M[i].h)y(s); X(i); } }
V(i){ C x,s,l,v,h,w,f[m=S],*d=f,*j=f+4,g[4],o; z(i-S||0*++B.p){ 
z(i==B.J|b[i])r 1; m=I; P g[x]=-1;
l=0; Q(e[i])z(b[s]||0*++l)z(v=p(s),b[s]^c)--M[*d=v].l||d++; else{ o=0; 
F(h,4)z(~(w=g[h]))o|=w==v;
l+=M[g[x]=v].l*!o-1; } z(!ld==f){ Q(e[i])b[s]^c^3||M[p(s)].l++; r 1; } 
M[i].l=l; B.s[b[i]=c]++;
u[B.i[u[--I]]=B.i[i]]=u[I]; Q(e[i])b[s]-c||(*j++=p(s),*j++=x); 
R(--jf+3)x=*j--,v=*j,M[M[v].p=i].h[x]=v;
R(d--f)y(*d); B.p=0; } B.J=m-I?-1:u[I-1]; c^=3; r 0; } Y(i,o){ C 
x,s,l=0,h[4]={ 0} ; Q(e[u[i]])l|=b[s]^o;
Q(a[u[i]])h[b[s]^3]++; else*h=1; r!lh[o]+*h2; } H(){ C 
x,s;t=18782*Q[v=v+14095]+_; _=t32; q=t+_;
z(q_)q++,_++; s=x=abs(Q[v]=-2-q)%I; do{ z(!Y(s,c)!V(u[s]))r 0; 
s++,s%=I; } R(s-x); V(S); }
D(L N*n){ n-h=n-g=n-w=0; } U(L N*n){ L N*h,*v=0; float l,j; C 
f=0,x,w=0; z(n-gW){ x=c;
R(B.p2abs(A)30f++2*S)H(); F(m,I)w+=Y(m,1)-Y(m,2); g=x^(A+w)0; Z=1; 
} else{
z(!n-h)F(f,I)Y(f,c)||(D(h=O+E++),h-i=u[f],h-s=n-h,n-h=h); l=-1; 
for(h=n-h; h;
h=h-s)j=~h-g?h-g?h-w/h-g+sqrt(log(n-g)/h-g)/2:9e9:-2,jl?l=j,v=h:0; 
v||(D(v=O+E++),v-i=S);
V(v-i)?v-g=-1,Z=0:U(v); } n-w+=gZ; n-g+=Z; g^=1; } main(){ C*x,*d; 
I=0; F(i,S){
X(i); B.s[i%3]=B.p=0; x=e[i]; d=a[i]; *d=(*x=i-W)-1; d[2]=(x[1]=i-1)+W; 
d[c=1]=(x[2]=i+1)-W; d[3]=1+(x[3]=i+W);
iW(*x=*d=d[1]=-1); i%W||(x[1]=*d=d[2]=B.J=-1); 
i%W^W-1||(x[2]=d[1]=d[3]=-1); iS-W||(x[3]=d[2]=d[3]=-1);
} R(B.p2){ z(cJ){ L N*h,*l; i=0; F=B; E=1; D(O); R(i++G)U(O),B=F; 
for(l=h=O-h; h;
h=h-s)z(h-gl-g~h-i)l=h; i=l-i; printx(%c%i\n,i%W+97,W-i/W); 
V(i); }

else R(gets(T)?*T64?J=*T,0:V(*T-80?*T-97+S-W*atoi(T+1):S):(exit(0),0));
F(m,S)printx(%c%c,b[m][.#o], \n[m%W+1==W]); } }


On 27/03/2015 21:55, Zach Wegner wrote:

With all the talk about Michi (which is very nice btw, Petr!), I
figured now would be a good time to do a little more work on my old
super-minimalist obfuscated Go engine, and finally show it off to the
world. Cogito was mostly written in 2008/2009, I only did some
cleaning up/bug fixing/shrinking.

At current count, using the IOCCC rules, there are only 1891
characters of C source code, or 2277 bytes if counted normally. It
only uses basic UCT with no eye-filling. I might try experimenting
with adding more heuristics, perhaps RAVE, as long as there isn't too
much code required. The code is certainly twisted and unintelligible,
but I might be convinced to write up some explanation of the code
structure and what all the one-character variable names mean...

Cogito has a simple terminal interface, but currently no way to play
through gtp. I once had a shell script that would interface it with
CGOS (where it played a bit in ~2009, with a rating of something like
1300), but it's been lost. I might whip up a little adapter script in
Python if there's interest. For just playing a terminal game, there's
some instructions in the readme.

Without further ado, the repository: https://github.com/zwegner/cogito
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5856 / Virus Database: 4315/9395 - Release Date: 03/27/15


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