Re: [Computer-go] Frisbee Go Simulation
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
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 Trompwrote: > 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?
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
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
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
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