[computer-go] Some Mogo 13x13 Games
Here are my first 10 13x13 games. Conditions as before, but with --13 -- pondering l options in the command line and 8.5 komi. Result: My wins: 10 Mogo wins: 0 I think that I can win 1000 games in a row because Mogo is unable to kill corners (against high dans). Therefore a 4 corner strategy is possible easily. One just has to be careful to live in each. In one game, I was greedy and almost got captured. Since then I am just playing safely for victory. As you might know, I am one of the strong 13x13 players. Nevertheless Mogo makes too little territory on average. Playing as White has been a bit easier for me because Mogo is stronger when he (as White) leads on territory. I agree with Mogo that 4-4 is a good first move on the 13x13. *** (;FF[4]CA[UTF-8]AP[GoGui:1.0.3]SZ[13] KM[8.5]TM[300]DT[2007-12-16]RE[W+Resign] ;B[jd]BL[299.0];W[dj]WL[297.0];B[ih]BL[293.0];W[kj]WL[289.0];B[cc]BL[286.0]; W[cg]WL[284.0];B[gh]BL[280.0];W[kg]WL[272.0];B[ce]BL[273.0];W[ib]WL[265.0] ;B[hc]BL[266.0];W[hb]WL[253.0];B[kh]BL[259.0];W[lh]WL[251.0];B[kc]BL[253.0]; W[fc]WL[244.0];B[gc]BL[248.0];W[gb]WL[242.0];B[dg]BL[242.0];W[ch]WL[239.0] ;B[kf]BL[236.0];W[jg]WL[233.0];B[fd]BL[229.0];W[ec]WL[228.0];B[db]BL[223.0]; W[eb]WL[226.0];B[ea]BL[219.0];W[fa]WL[224.0];B[da]BL[214.0];W[ic]WL[222.0] ;B[jf]BL[207.0];W[dd]WL[212.0];B[ee]BL[201.0];W[cd]WL[209.0];B[bd]BL[196.0]; W[be]WL[207.0];B[dc]BL[191.0];W[ed]WL[202.0];B[de]BL[189.0];W[fb]WL[201.0] ;B[bc]BL[188.0];W[gd]WL[191.0];B[hd]BL[184.0];W[fe]WL[189.0];B[ff]BL[178.0]; W[gf]WL[184.0];B[bf]BL[173.0];W[fg]WL[180.0];B[ig]BL[167.0];W[lf]WL[175.0] ;B[jh]BL[162.0];W[lg]WL[173.0];B[ef]BL[156.0];W[kb]WL[168.0];B[gg]BL[151.0]; W[lc]WL[161.0];B[dl]BL[145.0];W[ck]WL[158.0];B[ld]BL[139.0];W[jc]WL[155.0] ;B[kd]BL[136.0];W[ik]WL[143.0];B[fk]BL[129.0];W[cl]WL[141.0];B[lb]BL[123.0]; W[la]WL[139.0];B[kk]BL[116.0];W[jk]WL[134.0];B[lj]BL[111.0];W[li]WL[132.0] ;B[jj]BL[106.0];W[ki]WL[130.0];B[lk]BL[104.0];W[kl]WL[127.0];B[ll]BL[102.0]; W[jl]WL[126.0];B[lm]BL[99.0];W[ml]WL[121.0];B[mj]BL[91.0];W[gl]WL[115.0] ;B[gj]BL[86.0];W[fl]WL[113.0];B[mi]BL[80.0];W[mh]WL[110.0];B[le]BL[74.0];W[km] WL[108.0];B[ka]BL[68.0];W[mb]WL[104.0];B[bk]BL[60.0];W[bj]WL[100.0] ;B[el]BL[55.0];W[ek]WL[96.0];B[ei]BL[48.0];W[bg]WL[91.0];B[di]BL[41.0];W[ci] WL[88.0];B[ag]BL[34.0];W[ah]WL[86.0];B[mg]BL[27.0];W[mf]WL[81.0] ;B[hl]BL[19.0];W[hk]WL[79.0];B[me]BL[14.0];W[mm]WL[77.0]) *** (;FF[4]CA[UTF-8]AP[GoGui:1.0.3]SZ[13] KM[8.5]TM[300]PB[MoGo]DT[2007-12-16]RE[W+Resign] ;B[jd]BL[299.0];W[dj]WL[298.0];B[hg]BL[293.0];W[dc]WL[293.0];B[de]BL[286.0]; W[gc]WL[287.0];B[gk]BL[279.0];W[kj]WL[283.0];B[ci]BL[272.0];W[cj]WL[279.0] ;B[bj]BL[265.0];W[bk]WL[277.0];B[bi]BL[259.0];W[cl]WL[274.0];B[di]BL[252.0]; W[ej]WL[271.0];B[jk]BL[246.0];W[kk]WL[269.0];B[kl]BL[241.0];W[jj]WL[267.0] ;B[ik]BL[234.0];W[ll]WL[264.0];B[ic]BL[228.0];W[cd]WL[257.0];B[ce]BL[221.0]; W[be]WL[252.0];B[kh]BL[215.0];W[jl]WL[247.0];B[il]BL[212.0];W[km]WL[245.0] ;B[bf]BL[206.0];W[hj]WL[230.0];B[gj]BL[200.0];W[gi]WL[224.0];B[fi]BL[197.0]; W[gh]WL[219.0];B[hi]BL[191.0];W[hh]WL[215.0];B[ii]BL[188.0];W[ij]WL[213.0] ;B[ih]BL[184.0];W[gg]WL[208.0];B[gf]BL[180.0];W[eh]WL[194.0];B[eg]BL[176.0]; W[fh]WL[180.0];B[ei]BL[174.0];W[ig]WL[178.0];B[jg]BL[171.0];W[hf]WL[176.0] ;B[he]BL[169.0];W[jh]WL[173.0];B[ji]BL[165.0];W[ki]WL[172.0];B[jh]BL[161.0]; W[jf]WL[171.0];B[kf]BL[157.0];W[lh]WL[170.0];B[kg]BL[155.0];W[ff]WL[158.0] ;B[ge]BL[154.0];W[ef]WL[150.0];B[dg]BL[151.0];W[fg]WL[148.0];B[fe]BL[147.0]; W[fj]WL[138.0];B[fk]BL[145.0];W[hk]WL[131.0];B[ke]BL[140.0];W[ek]WL[118.0] ;B[bc]BL[133.0];W[bd]WL[114.0];B[cb]BL[129.0];W[db]WL[112.0];B[hl]BL[125.0]; W[fl]WL[109.0];B[gl]BL[123.0];W[el]WL[106.0];B[cc]BL[117.0];W[dd]WL[103.0] ;B[ee]BL[115.0];W[gm]WL[100.0];B[da]BL[110.0];W[eb]WL[92.0];B[ea]BL[103.0]; W[fa]WL[86.0];B[ca]BL[101.0];W[fb]WL[80.0];B[ac]BL[100.0];W[ad]WL[74.0] ;B[dh]BL[95.0];W[im]WL[72.0];B[df]BL[91.0];W[hm]WL[70.0]) *** (;FF[4]CA[UTF-8]AP[GoGui:1.0.3]SZ[13] KM[8.5]TM[300]PB[MoGo]DT[2007-12-16]RE[W+Resign] ;B[jd]BL[299.0];W[dj]WL[298.0];B[gh]BL[292.0];W[cg]WL[294.0];B[ji]BL[286.0]; W[gc]WL[290.0];B[ed]BL[280.0];W[jb]WL[288.0];B[fe]BL[274.0];W[kd]WL[286.0] ;B[kc]BL[269.0];W[jc]WL[284.0];B[ke]BL[265.0];W[ld]WL[283.0];B[lc]BL[263.0]; W[le]WL[280.0];B[id]BL[257.0];W[hc]WL[271.0];B[lf]BL[253.0];W[kf]WL[268.0] ;B[je]BL[249.0];W[lg]WL[266.0];B[kb]BL[247.0];W[cd]WL[261.0];B[ic]BL[243.0]; W[ib]WL[259.0];B[ja]BL[241.0];W[hb]WL[256.0];B[kg]BL[236.0];W[jf]WL[252.0] ;B[he]BL[234.0];W[kh]WL[247.0];B[jg]BL[230.0];W[mf]WL[244.0];B[li]BL[225.0]; W[jh]WL[241.0];B[ig]BL[222.0];W[lh]WL[236.0];B[eb]BL[215.0];W[la]WL[231.0] ;B[ci]BL[208.0];W[cj]WL[227.0];B[bi]BL[202.0];W[di]WL[225.0];B[dh]BL[196.0]; W[ch]WL[223.0];B[lb]BL[189.0];W[mc]WL[216.0];B[md]BL[184.0];W[me]WL[213.0]
Re: [computer-go] Lisp time
The same facts of the invalidity of benchmarks continue to surface, and it's well understood that they can be misleading - but for me the very simple truth is straightforward.I have tried many different languages and in every case so far it has not turned out unclear, C has always won. So yes, it's possible to draw the wrong conclusions and yes benchmarks will always have flaws in them, and yes it's more important to optimize the algorithm and yes certain optimizations work better on some CPU's than others and ... so on and so on. This is all true. But I have found so far that the performance advantage of C is so overwhelming that my first unoptimized attempt in C produces a faster program than in other languages. Stefan has said that C is a lousy performance language and that it's only fast if you go to great lengths to make it so.That is completely contrary to my own experience. One of the reasons I do performance coding in C is that I can produce faster code on my first try than I can with any other language.Again, contrary to what Stefan thinks, I have found that if you want fast code in any language you have to work at it and that usually means you have to ugly it up a little.I haven't seen that any language is immune to that. One thing is really clear to me. I will spend less time writing C code (without worrying too much about optimizations) that I will spending an enormous time trying to make one of these ideal languages run almost as fast. Yes, in theory there may be a couple of languages that have potential to beat C. But that is no good to me now.When theory becomes reality I will be the first to change over. As has been mentioned before, the amount of effort gone into C compiler technology is probably responsible for this.I seriously doubt any other language has had so much effort devoted to squeezing so much from them. If that had been the case then C probably would be a close second or third in speed. There is also something else to keep in mind. There is not even a discussion when it comes to the vast majority of languages because we are talking 5-100 X slower than C in most cases.A language starts to get interesting when it is within 2X factor of C.In which case it is usually almost as fast as C if you turn all optimizations off for C and all optimization on for the other language. I'm not a C enthusiast, I wish it were different. I don't like C. I continue to look for it's replacement. - Don Stefan Nobis wrote: Isaac Gouy [EMAIL PROTECTED] writes: Again, you seem happy to say they are overrated and dismiss them without actually having looked - that is not scientific! Yes, my critique is not up to the standards I measure the shootout with. But my main point is: Performance has so many (sometimes hard to recognize) parameters that's really easy to draw false conclusions From some benchmark data. If you are interested for the best performance for you task at hand, you have to do benchmarks within your execution environment and you have to construct benachmarks that really resemble your task. Different OS, different CPU, even different cache sizes, different alogrithms and so on. All these things really matter and if you change any of these parameters the whole picture may change (on OS A, CPU B compiler S for language X may be produce code that executes faster for a benchmark than the code that is produced by compiler T for language Y on the same system, but on CPU C the combination T/Y may be better). One extra problem: As far as I can see you only compare freely available language implementations (and this point is overssen by many people -- I'm a big open source fan, but more often than not there is one or more commercial language implementation that produce better results than any of the freely available implementations). These games are funny and sometimes it's even possible to come to helpful conclusions given the data. But many people I talked with understand these shootouts as hard facts, they assume language X is always better than language Y and don't take into account for example that they are developing for a Sparc cluster while using benchmarks for Intel/AMD. OK, so I would say I don't really have any problems with the shootout but with the perception of these shootouts by many people. And that's why I dislike these shootouts in general. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Lisp time
hey, something fun! keeping pipelines full and carefully scheduling when cache will be flushed is another. not as performance-killing as branching, perhaps, but equally tedious to do by hand. one very cool thing about the ultrasparc (and likely many other processors) is that it could schedule 4 instructions at once: an int op, a float op, a load and a store. of course, main memory access is terrible, but if you could figure out how to equally divide time between int and float ops, you could make a killing. also useful are the many different graphics ops that can be repurposed with some heavy-handed engineering. i *believe* that some sparc cpus from the wayback machine could renumber some of their registers with a single (quick) instruction. some cute tricks ca. 1991: use the 4x4 matrix multiplier (also known as the instruction that rotates and translates sets of points in 3-space) on an SGI to do arbitrary matrix calculations, in 4x4 chunks. i think that this is common now. for efficient graphics updating, there is usually a ginormous pile of very fast ram sitting around that can be manhandled into dealing with partial results. older sgi's have tons of ram like this. this should be commonly done, if it isn't. and of course: stare at the instruction list provided by the manufacturer for a long time to see if there are any weird instructions that could be used in not-quite-as-intended ways. some of these can be found on the GPU, if there is one. probably modern graphics cards on pc's should be busy doing anything other than graphics, since they're so overpowered and are connected to the cpu via such an extremely fast channel. your monitor might look weird for awhile (or not), but man, you should be able to calculate like a mofo. and just to reiterate the earlier branching comment: if you see an if anywhere in your code, just imagine that you're causing yourself a very painful slowdown if it's true on the order of 50% of the time, false 50% of the time. and if it's almost always true or false, think about how to get rid of it or minimize the number of times it gets evaluated (or at the very least, how to advise the compiler to advise the cpu that it will be true or false most of the time). s. Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] language efficiency
Intel makes compilers for C, C++, and Fortran. As far as I can tell, they do not make compilers for Lisp, Haskell, OCaml, or any other higher-level languages. Intel knows more about how to get the most out of their own chips, than just about anybody else. Intel compilers are a means to make their chips look good, so naturally a lot of effort goes into making them work right. When you speak of other languages, few people have the resources and the specialized expertise to properly take advantage of the chips. Indeed, many higher-level compilers use C as an intermediate language, the better to leverage existing work on optimization and support of multiple targets. Why reinvent the wheel? It isn't easy to support multiple varieties of the Power, x86, MIPS, SPARC, and umpty-seven other architectures. C makes a handy portable target. The SSE4 SIMD (single instruction, multiple data ) instructions http://en.wikipedia.org/wiki/SSE4 - introduced with the Penryn chips, makes for interesting reading. There are instructions for dot products, the sum of absolute differences, counting bits in a population in a single cycle, and so forth. It would take a clever compiler to find opportunities to use these effectively. Terry McIntyre [EMAIL PROTECTED] Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Lisp time
--- Stefan Nobis [EMAIL PROTECTED] wrote: Isaac Gouy [EMAIL PROTECTED] writes: Again, you seem happy to say they are overrated and dismiss them without actually having looked - that is not scientific! Yes, my critique is not up to the standards I measure the shootout with. But my main point is: Performance has so many (sometimes hard to recognize) parameters that's really easy to draw false conclusions From some benchmark data. Yes, and it's really really really easy to guess or assume false conclusions without looking at any data! :-) If you are interested for the best performance for you task at hand, you have to do benchmarks within your execution environment and you have to construct benachmarks that really resemble your task. Different OS, different CPU, even different cache sizes, different alogrithms and so on. All these things really matter and if you change any of these parameters the whole picture may change (on OS A, CPU B compiler S for language X may be produce code that executes faster for a benchmark than the code that is produced by compiler T for language Y on the same system, but on CPU C the combination T/Y may be better). Yes, and people can see some of that by just by comparing the benchmarks game measurements of the same programs made on the AMD Sempron machine and on the Intel P4 machine. Some of them even read about Flawed Benchmarks http://shootout.alioth.debian.org/gp4/miscfile.php?file=benchmarkingtitle=Flawed%20Benchmarks One extra problem: As far as I can see you only compare freely available language implementations (and this point is overssen by many people -- I'm a big open source fan, but more often than not there is one or more commercial language implementation that produce better results than any of the freely available implementations). Yes, and if you had looked at the website you would know that we talk insistently about programming language /implementations/. How can we benchmark a programming language? We can't - we benchmark programming language implementations. How can we benchmark language implementations? We can't - we measure particular programs. http://shootout.alioth.debian.org/ These games are funny and sometimes it's even possible to come to helpful conclusions given the data. But many people I talked with understand these shootouts as hard facts, they assume language X is always better than language Y and don't take into account for example that they are developing for a Sparc cluster while using benchmarks for Intel/AMD. So when you talk with those people, point them to examples in the benchmarks game that contradict their simplistic understanding. OK, so I would say I don't really have any problems with the shootout but with the perception of these shootouts by many people. And that's why I dislike these shootouts in general. You seem to be arguing that those people would have a more accurate understanding of performance if they had less data! :-) Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] language efficiency
On 16/12/2007, terry mcintyre [EMAIL PROTECTED] wrote: Intel makes compilers for C, C++, and Fortran. As far as I can tell, they do not make compilers for Lisp, Haskell, OCaml, or any other higher-level languages. Intel also funds work (directly or indirectly) on the GCC suite, which compiles languages such as Java, and there are lisp implementations in Java... Why reinvent the wheel? Reinventing the wheel is necessary if you don't want to be lumbered with the limitations of the wheel. Some of the problems with C include: * linking conventions inherited from Fortran and now 30 years behind modern ideas in software engineering * compile time rather than runtime portability * lack of dynamic modifications of the runtime There are issues such as poor support for network protocols, Unicode, threading, etc., but (as you correctly point out) these can be remedied by using a high level language which uses C as an intermediate language. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MC-UCT and tactical information
On Dec 14, 2007 2:29 PM, David Fotland [EMAIL PROTECTED] wrote: Many Faces does life and death search at the root before the main search. It typically allocates a few hundred nodes to life and death search. Since the search is best-first, it keeps the search trees from move to move. Later searches can extend earlier ones. The trees are small, so it doesn't cost much to keep them. During evaluation tactical search results are cached, but the search tree is not. During a main search to find the move to play, Many Faces does a few million nodes of tactical search, so it's too much to cache. David Dave, will Many Faces 12 be able to take advantage of multiple processors? ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] MC-UCT and tactical information
Not version 12, but I expect I'll have to implement multiprocessing some day. Since the number of cores will double every 2 years, in 20 years we'll have PCs with over 1000 CPUs :) David -Original Message- From: [EMAIL PROTECTED] [mailto:computer-go- [EMAIL PROTECTED] On Behalf Of Chris Fant Sent: Sunday, December 16, 2007 7:23 PM To: computer-go Subject: Re: [computer-go] MC-UCT and tactical information On Dec 14, 2007 2:29 PM, David Fotland [EMAIL PROTECTED] wrote: Many Faces does life and death search at the root before the main search. It typically allocates a few hundred nodes to life and death search. Since the search is best-first, it keeps the search trees from move to move. Later searches can extend earlier ones. The trees are small, so it doesn't cost much to keep them. During evaluation tactical search results are cached, but the search tree is not. During a main search to find the move to play, Many Faces does a few million nodes of tactical search, so it's too much to cache. David Dave, will Many Faces 12 be able to take advantage of multiple processors? ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] How does MC do with ladders?
Forrest, similar multi-level or hierarchical/partitioned search concepts have been suggested by several people here over the years, myself included many times. I first suggested a chunking probability based search concept back in 1998. I have long been an advocate of goal-directed hierarchical search for Go, but haven't yet figured out how to make it work in practice. I tried some things years before MC/UCT popped up without any real success. There could perhaps be some promise in finding ways to combine some of these multi-level ideas with MC/UCT search techniques. I don't understand the follow-up to your post claiming that you can't do this for these kinds of games because they are not forcing move sequences. We're talking about the play-out part of the search used to sample the game tree. Anything goes, right? Of course, whether any particular play-out method helps or not is another question. -Matt Forrest Curo wrote: It's the approach I believe to be more human-like. Not necessarily the playing style. Human beings chunk. What all this fuss suggests to me is a meta-mc program... You include routines that work out good sequences, as a human would--and then you have the random part of the program include the more promising sequences, where applicable, as if they were individual moves. Forrest Curo This message was sent using IMP, the Internet Messaging Program. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
