Re: [Computer-go] (no subject)
On 4/1/16 9:40 AM, Petr Baudis wrote: On Fri, Apr 01, 2016 at 07:08:34AM +0200, Robert Jasiek wrote: On 01.04.2016 02:22, djhbrown . wrote: kogo is great for corner openings Kogo contains many mistakes. Too many kyus got their hands on it. It would be better to spend 3+ weeks using kombilo on GoGoD and create a new joseki tree. A summary of such an effort (with some interesting, additional, old variations) you find in Joseki 3 - Dictionary. (If someone is lazy or has trouble setting up kombilo, a great and extremely approachable way to try this online is http://ps.waltheri.net/ ) As a player, I find http://www.josekipedia.com/ useful. Michael ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] (no subject)
On Fri, Apr 01, 2016 at 07:08:34AM +0200, Robert Jasiek wrote: > On 01.04.2016 02:22, djhbrown . wrote: > >kogo is great for corner openings > > Kogo contains many mistakes. Too many kyus got their hands on it. > > It would be better to spend 3+ weeks using kombilo on GoGoD and create a new > joseki tree. A summary of such an effort (with some interesting, additional, > old variations) you find in Joseki 3 - Dictionary. (If someone is lazy or has trouble setting up kombilo, a great and extremely approachable way to try this online is http://ps.waltheri.net/ ) -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] (no subject)
On 01.04.2016 02:22, djhbrown . wrote: kogo is great for corner openings Kogo contains many mistakes. Too many kyus got their hands on it. It would be better to spend 3+ weeks using kombilo on GoGoD and create a new joseki tree. A summary of such an effort (with some interesting, additional, old variations) you find in Joseki 3 - Dictionary. -- robert jasiek ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] (no subject)
on the subject of tools for learning josekis, i would love to have to the help of a computerised assistant who could show me a flip-through "photo album" of how alternative paths in a joseki end up, without having to plod along the paths (which to me is a dark and mysterious tree of paths in a dark and mysterious forest) the thing about josekis is not where you start, nor even where you step, but where you end up i'd love to have kogo sitting inside a game playing client which could assist me by offerring the following navigation functions: - click on last move to initiate a matchup with kogo and start a flip-through by spacebar of just the ends of the main lines of variations starting from there, so i can see which variation would suit the game position i am in. that way i can start to learn where josekis end instead of just where they start. - right/left arrows crawl forward/back along a branch - up/down arrows jump up/down (to the start of) variation branches. (think of the tree as being laid out sideways) - click on variation being shown to make its first move on the gameboard, - backspace or esc to return to own play mode. i am unaware of any existing client/editor that has these variation navigation buttons in just the way i have described; the ones i use right now are cgoban and gogui - the latter because it loads kogo miles quicker than cgoban usability is inversely proportional to programmability; this would be easy for users but a bit of work for a developer. PS kogo is great for corner openings, but there are also middle edge and yose josekis that pros learn and occasionally mention in video lectures, so if they were included too, that would help us novices out a lot. -- 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
Re: [Computer-go] (no subject)
On 31.03.2016 16:54, Bill Whig wrote: Wouldn't you agree that a lot of people (most?) might might advance more swiftly > with move suggestions rather than text that they have to work through like a textbook? I say the opposite. Move suggestions without any additional information are meaningless. There are different learning styles, among them learning by example and learning by theory. Learning by example is not "learning by move suggestions" but is "learning by example moves, example sequences or example positions etc. TOGETHER WITH SOME additional information, such as move together with shape, move together with the positional context, move together with tactical reading and decision-making etc. I have never seen or heard of anybody learning ONLY by example or ONLY by theory. I see all strong players, including those preferring learning by example, having a good explicit or implicit textbook knowledge. "swiftly" versus "have to work through" creates a false impression. Learning by example requires very many examples. Learning by textbook theory requires learning an only intermediate number of theoretical bits. (Learning by move suggestions, i.e., without any additional information, is the slowest. It becomes efficient only for AI having the compuational power to simulate thousands of man-years of learning.) > I haven't ready any of your books, but I've read a > few Go books and most of them do not do justice to the complexity of the game. So you have read the wrong books. "Move suggestions" would invite the student to think in more creative, and effective, ways > than I have seen put forth in any book thus far. 1) Even ABC move suggestion books do not just suggest moves but also provide positional context. 2) You have a totally wrong view on creative, effective thinking if you do not consider the possibility of having it when studying theory. 3) You have read the wrong books. > Most say that the first thing that one should do after learning joseki is to forget it... . It is possible that this nonsense is still believed by a majority. Overcome it, see e.g. a report suggesting differently: http://www.lifein19x19.com/forum/viewtopic.php?f=57=12951 A better advice is: improve while studying joseki by understanding them and their theory. The bad proverbs are about learning josekis without understanding: learn, forget, repeat; this effort can demote a player's strength indeed;) -- robert jasiek ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
[Computer-go] (no subject)
Message: 1 Date: Thu, 31 Mar 2016 14:33:39 +0200 From: Robert Jasiek <jas...@snafu.de> To: computer-go@computer-go.org Subject: Re: [Computer-go] new challenge for Go programmers Message-ID: <56fd1923.4080...@snafu.de> Content-Type: text/plain; charset=UTF-8; format=flowed On 31.03.2016 13:43, Bill Whig wrote: Joseki learning requires much more than move suggestions. Prove it. Read my four joseki books and my two books on positional judgement for a proof. Hints: global context, evaluation, strategic choices, tactical reading, many strategic concepts etc. All these are required for good human joseki play and (far) beyond move suggestions. -- robert jasiek -- Message: 2 Date: Thu, 31 Mar 2016 08:43:22 -0500 From: "Jim O'Flaherty" <jim.oflaherty...@gmail.com> To: computer-go@computer-go.org Subject: Re: [Computer-go] new challenge for Go programmers Message-ID:
Re: [computer-go] (no subject)
In message 20100104070048.50...@gmx.net, Ingo Althöfer 3-hirn-ver...@gmx.de writes Hello all, especially hello Nick, http://www.weddslist.com/kgs/future.html are there already plans for KGS bot tournaments in 2010? Yes. I must set up a schedule this week. I plan to continue last year's rota of monthly events, and to have a couple of extra events with unusual schedules. I have discussed these extra events in the past, and received feedback here; which, unfortunately, I have forgotten. So please, anyone who is interested, make your suggestions now. One possibility is a slow event on full boards. Five rounds, Swiss, twelve hours each, to be played over a (GMT) Monday-Tuesday-Wednesday-Thursday-Friday. Nick -- Nick Weddn...@maproom.co.uk ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] (no subject)
Le 04/01/2010 à 14:19, Nick Wedd a écrit : I have discussed these extra events in the past, and received feedback here; which, unfortunately, I have forgotten. So please, anyone who is interested, make your suggestions now. As a spectator i would like an Hanh tournament on 19x19, not too fast (~30 min each). I can run one bot if needed (gnugo fuego) Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] (no subject)
On Mon, Jan 04, 2010 at 01:19:25PM +, Nick Wedd wrote: In message 20100104070048.50...@gmx.net, Ingo Althöfer 3-hirn-ver...@gmx.de writes Hello all, especially hello Nick, http://www.weddslist.com/kgs/future.html are there already plans for KGS bot tournaments in 2010? Yes. I must set up a schedule this week. I plan to continue last year's rota of monthly events, and to have a couple of extra events with unusual schedules. I have discussed these extra events in the past, and received feedback here; which, unfortunately, I have forgotten. So please, anyone who is interested, make your suggestions now. One possibility is a slow event on full boards. Five rounds, Swiss, twelve hours each, to be played over a (GMT) Monday-Tuesday-Wednesday-Thursday-Friday. I'm personally fairly happy with the current tournament system, though this kind of event would be quite interesting too, I'm just not sure if too many problems both with software and KGS wouldn't disrupt it too much... (And I would have to implement tree garbage collection sooner than expected. ;) On Mon, Jan 04, 2010 at 05:53:46PM +0100, Alain Baeckeroot wrote: Le 04/01/2010 à 14:19, Nick Wedd a écrit : I have discussed these extra events in the past, and received feedback here; which, unfortunately, I have forgotten. So please, anyone who is interested, make your suggestions now. As a spectator i would like an Hanh tournament on 19x19, not too fast (~30 min each). I can run one bot if needed (gnugo fuego) I don't think Hahn tournament would be that interesting, it would require some extensive modifications of especially the top programs and involve a lot of work in the tournament setup as well. (And, ~30 min each _is_ quite fast on 19x19. ;) Petr Pasky Baudis ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] (no subject)
In message 201001041753.46668.alain.baecker...@laposte.net, Alain Baeckeroot alain.baecker...@laposte.net writes Le 04/01/2010 à 14:19, Nick Wedd a écrit : I have discussed these extra events in the past, and received feedback here; which, unfortunately, I have forgotten. So please, anyone who is interested, make your suggestions now. As a spectator i would like an Hanh tournament on 19x19, not too fast (~30 min each). I can run one bot if needed (gnugo fuego) I assume you mean Hahn. Google tells me that Hanh is a Vietnamese surname. I'll do that. I'll make it a round robin tournament (or double round robin if there are too few entrants) so that KGS can do the pairings; and then calculate the results manually. I'll assume that entrants will configure their bots to maximise score, or at least, not to resign. Nick Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ -- Nick Weddn...@maproom.co.uk ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] (no subject)
On Jan 4, 2010, at 9:09 AM, Petr Baudis wrote: I don't think Hahn tournament would be that interesting, it would require some extensive modifications of especially the top programs and involve a lot of work in the tournament setup as well. I agree -- the Hahn game changes the victory conditions so radically as to be a different game. Peter Drake http://www.lclark.edu/~drake/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] (no subject) wish hahn
Le 04/01/2010 à 18:09, Petr Baudis a écrit : I don't think Hahn tournament would be that interesting, As a physicist i like to experiment first, and think later, to understand what happened, which obviously was not foreseen ;-) I believe it will reveal some hidden aspect of the stronger engines, and for sure it will be *fun* to see stronger bots destroy weaker ones, (MC-RAVE end-game of strong bots is boring on 19x19) it would require some extensive modifications of especially the top programs No need to be perfect Hahn. Changing the aim to max_points seems to be just a change in metrics, it does not looks like very complicate and involve a lot of work in the tournament setup as well. This is solved by Nick Wedd (And, ~30 min each _is_ quite fast on 19x19. ;) I'll help you to convince Nick to give more time to your bot :) Alain. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] (no subject)
Hello all, especially hello Nick, http://www.weddslist.com/kgs/future.html are there already plans for KGS bot tournaments in 2010? Cheers, Ingo. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] (no subject)
Jeff Nowakowski wrote: On Wed, Aug 19, 2009 at 07:27:00AM -0700, terry mcintyre wrote: Consider the game when computer is black, with 7 stones against a very strong human opponent. ... Didn't this game actually happen? Didn't MoGo *beat* a pro with 7 stones? It was long ago: in February 2009, and it was only the first game in a series of 6 games. All other five games in that event were won by the humans. Later, only one more bot-win against a low pro at h7. http://www.computer-go.info/h-c/index.html Without special techniques the h7 wall will stand for a long time. Ingo. PS: Once again I would like to mention my report on Laziness of Monte Carlo, at http://www.althofer.de/mc-laziness.pdf In the meantime, a student has found the same phenomenon in UCT search (instead of basic MC). Also in discrete online optimization (so outside of combinatorial games) it has been observed by another Ph.D. student of mine: porcedures on Monte Carlo basis are stronger when they have the impression that the situation is tense. -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] (no subject)
PS: Once again I would like to mention my report on Laziness of Monte Carlo, at http://www.althofer.de/mc-laziness.pdf In the meantime, a student has found the same phenomenon in UCT search (instead of basic MC). Also in discrete online optimization (so outside of combinatorial games) it has been observed by another Ph.D. student of mine: porcedures on Monte Carlo basis are stronger when they have the impression that the situation is tense. Laziness is something we all agree on. This is not in dispute. But how do you create the required tension in a way that produces a program that plays the game better? I don't mean selected positions, but the entire game. - Don -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ 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] (no subject)
I like the idea very much. But the coding effort is mostly in the GUI so it depends whether gogui's (or other GUIS's) author will like the idea. It has great commercial/popularity potential. But it is not so important for research. Lukasz On Tue, Apr 21, 2009 at 07:35, Ingo Althöfer 3-hirn-ver...@gmx.de wrote: Hello, during the last weekend I have tried (for the first time) to use commercial go programs to analyse some games played between human players (on KGS). The idea was to use the bots for blunderchecks. So, I was looking for positions where the evaluation (in win percentages) jumped or dropped between consecutive moves. *** Concrete Example *** Amongst others I looked at a game between bwilcox[3d] and harleqin [2d], played on April 20, 2009, starting time 5:31 [CEST]. You can download the sgf for instance from the KGS archive at http://www.gokgs.com/gameArchives.jsp?user=Harleqin (By the way, bwilcox might be Bruce Wilcox, one of the veterans in computer go.) Both programs in my analysis claimed that 77.f13 was a big error: * In Leela the score dropped from 50.5 to 41.4 . * In ManyFaces the score dropped from 50.0 to 45.8 . Instead of 77.f13, both programs proposed 77.d14, with the possible continuation 78.e14 79.d13 . I discussed these findings with Harleqin, and he agreed that 77.f13 was a move that brought him into problems. *** General Wish *** Unfortunately current, (commercial) go programs (including Leela and ManyFaces) do not have a user interface that allows for COMFORTABLE analysis of games. The user has to click lots of buttons when jumping back and forth in some sgf. My wish is to have something similar to that, what has become standard in computer chess programs in the mid 1990's: * on the left half of the screen the diagram of the board * on the right half a list (not only sgf, but also with move numbers included) * the program is computing in analysis (infinite) mode * when the user clicks (by mouse) on any move in the move list then the program jumps immediately to this position and starts analysing (of course this position is shown in the diagram) * of course the screen should all the time show (in fat font) what the value of komi in the game under investigation is. * Another big wish: the programs should allow for some k-best mode where not only the best but the k best moves are computed (k being some integer specified by the user). Ingo. -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ 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] (no subject)
Yes, this is a powerful feature that all chess interfaces have. There is one issue with GTP that will have to be kludged around - there is no way to stop an engine from thinking that is provided naturally by gtp. GTP has the nice feature that you can pipe in commands from a file, but it's not an ideal protocol for a sophisticated interface. Therefore, it is impossible to build a workable interface for all programs without requiring some basic modification to the protocol. I believe the protocol should have a special mode for this, the ability to accept commands even while busy - the ability to communicate asynchronously which is required to build the more sophisticated interfaces. I don't want to open up a can of worms here - this has been discussed on this list before. But it's a necessary step that will have to be taken sooner or later and I would personally prefer it's hea - Don On Tue, Apr 21, 2009 at 5:48 AM, Łukasz Lew lukasz@gmail.com wrote: I like the idea very much. But the coding effort is mostly in the GUI so it depends whether gogui's (or other GUIS's) author will like the idea. It has great commercial/popularity potential. But it is not so important for research. Lukasz On Tue, Apr 21, 2009 at 07:35, Ingo Althöfer 3-hirn-ver...@gmx.de wrote: Hello, during the last weekend I have tried (for the first time) to use commercial go programs to analyse some games played between human players (on KGS). The idea was to use the bots for blunderchecks. So, I was looking for positions where the evaluation (in win percentages) jumped or dropped between consecutive moves. *** Concrete Example *** Amongst others I looked at a game between bwilcox[3d] and harleqin [2d], played on April 20, 2009, starting time 5:31 [CEST]. You can download the sgf for instance from the KGS archive at http://www.gokgs.com/gameArchives.jsp?user=Harleqin (By the way, bwilcox might be Bruce Wilcox, one of the veterans in computer go.) Both programs in my analysis claimed that 77.f13 was a big error: * In Leela the score dropped from 50.5 to 41.4 . * In ManyFaces the score dropped from 50.0 to 45.8 . Instead of 77.f13, both programs proposed 77.d14, with the possible continuation 78.e14 79.d13 . I discussed these findings with Harleqin, and he agreed that 77.f13 was a move that brought him into problems. *** General Wish *** Unfortunately current, (commercial) go programs (including Leela and ManyFaces) do not have a user interface that allows for COMFORTABLE analysis of games. The user has to click lots of buttons when jumping back and forth in some sgf. My wish is to have something similar to that, what has become standard in computer chess programs in the mid 1990's: * on the left half of the screen the diagram of the board * on the right half a list (not only sgf, but also with move numbers included) * the program is computing in analysis (infinite) mode * when the user clicks (by mouse) on any move in the move list then the program jumps immediately to this position and starts analysing (of course this position is shown in the diagram) * of course the screen should all the time show (in fat font) what the value of komi in the game under investigation is. * Another big wish: the programs should allow for some k-best mode where not only the best but the k best moves are computed (k being some integer specified by the user). Ingo. -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] (no subject)
My email got cut off near the end.My final thought was that it would be preferable to stick with GTP, just a revised asynchronous version. - Don 2009/4/21 Don Dailey dailey@gmail.com Yes, this is a powerful feature that all chess interfaces have. There is one issue with GTP that will have to be kludged around - there is no way to stop an engine from thinking that is provided naturally by gtp. GTP has the nice feature that you can pipe in commands from a file, but it's not an ideal protocol for a sophisticated interface. Therefore, it is impossible to build a workable interface for all programs without requiring some basic modification to the protocol. I believe the protocol should have a special mode for this, the ability to accept commands even while busy - the ability to communicate asynchronously which is required to build the more sophisticated interfaces. I don't want to open up a can of worms here - this has been discussed on this list before. But it's a necessary step that will have to be taken sooner or later and I would personally prefer it's hea - Don On Tue, Apr 21, 2009 at 5:48 AM, Łukasz Lew lukasz@gmail.com wrote: I like the idea very much. But the coding effort is mostly in the GUI so it depends whether gogui's (or other GUIS's) author will like the idea. It has great commercial/popularity potential. But it is not so important for research. Lukasz On Tue, Apr 21, 2009 at 07:35, Ingo Althöfer 3-hirn-ver...@gmx.de wrote: Hello, during the last weekend I have tried (for the first time) to use commercial go programs to analyse some games played between human players (on KGS). The idea was to use the bots for blunderchecks. So, I was looking for positions where the evaluation (in win percentages) jumped or dropped between consecutive moves. *** Concrete Example *** Amongst others I looked at a game between bwilcox[3d] and harleqin [2d], played on April 20, 2009, starting time 5:31 [CEST]. You can download the sgf for instance from the KGS archive at http://www.gokgs.com/gameArchives.jsp?user=Harleqin (By the way, bwilcox might be Bruce Wilcox, one of the veterans in computer go.) Both programs in my analysis claimed that 77.f13 was a big error: * In Leela the score dropped from 50.5 to 41.4 . * In ManyFaces the score dropped from 50.0 to 45.8 . Instead of 77.f13, both programs proposed 77.d14, with the possible continuation 78.e14 79.d13 . I discussed these findings with Harleqin, and he agreed that 77.f13 was a move that brought him into problems. *** General Wish *** Unfortunately current, (commercial) go programs (including Leela and ManyFaces) do not have a user interface that allows for COMFORTABLE analysis of games. The user has to click lots of buttons when jumping back and forth in some sgf. My wish is to have something similar to that, what has become standard in computer chess programs in the mid 1990's: * on the left half of the screen the diagram of the board * on the right half a list (not only sgf, but also with move numbers included) * the program is computing in analysis (infinite) mode * when the user clicks (by mouse) on any move in the move list then the program jumps immediately to this position and starts analysing (of course this position is shown in the diagram) * of course the screen should all the time show (in fat font) what the value of komi in the game under investigation is. * Another big wish: the programs should allow for some k-best mode where not only the best but the k best moves are computed (k being some integer specified by the user). Ingo. -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] (no subject)
Hello, a small set of a low dan datapoints: I've been playing 9x9 go against MoGoBot on KGS as white (with guest acount guest47) with komi 0,5. My result sofar is 4 wins and 9 losses, which was a nice surprise for me (as an European 3 dan), since I wasn't expecting MoGoBot to be that strong. I'm curious to know, how many playouts (in Sensei's 100k is mentioned for CGOS) MoGoBot plays, i.e., how serious version is it? -Esa ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] (no subject)
Hello, I'm curious to know, how many playouts (in Sensei's 100k is mentioned for CGOS) MoGoBot plays, i.e., how serious version is it? This version plays on a intel core2 duo, and on a 10 minutes game, it makes between 40 and 5 playouts per move (more at the beginning). The current version is the one which participated to last KGS tournament this sunday, and is called MoGo_G3.4bb on the new CGOS. BTW, on CGOS it is rated incredibly weaker than the G3.4 version (lesson n°1 never try new untested parameters on a tournament :-p). I still don't understand how it can change so much between G3.4 and G3.4bb, maybe it is not noticeable for humans? It is really a surprise for me. BTW Don, is it possible to have access to crosstables of old standings on old CGOS (http://cgos.boardspace.net/9x9.html), it may useful for some in some situations to see old versions (at least for some time). I hope I answer here your questions. Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] (no subject)
This version plays on a intel core2 duo, and on a 10 minutes game, it makes between 40 and 5 playouts per move (more at the beginning). snip I hope I answer here your questions. Sylvain Thanks for the info, my desire of MoGoBot knowledge has been satisfied ;) -Esa ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] another subject?
On 3/25/07, forrest curo [EMAIL PROTECTED] wrote: Does this bunch ever get around to the merits of various ways of representing the board and arriving at moves? Sure, e.g.: http://computer-go.org/pipermail/computer-go/2006-December/thread.html#7452 For example, something I suggested the last time I was on a computer go list, back in the 90's: Take an array of 7 64-bit integers... It seems you have lots of catching up to do in reading the old archives... E. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] another subject?
For example, something I suggested the last time I was on a computer go list, back in the 90's: Take an array of 7 64-bit integers... I believe very similar techniques are pretty common - I don't know how common but it's been used before. I believe you might as well just use use bit-boards - where one color is represented as a single large integer. For a large board such as 19x19 (or even 9x9) you have to fake it, building your own routines or using a bignum library to do the shifts and other logical operations - but it's still very fast for many operations. Shifting is a bit of a bottleneck but on a 64 bit computer you are doing a lot of work in parallel with a 64 bit shift.One good thing about this is most operations do not require conditional branching which can be a killer to modern processors when it's not easy to predict which direction the branch will go.I don't keep up with this much these days - perhaps the state of the art has improved? I did such a move generator in a high level language. It's very tiny, as the code to make and test a move are just a few logical operators. So the code to do this is very clean and compact and is quickly debugged. It's a little inconvenient to decode a bit board - for instance if you have a bit board representing all the legal moves and you wish to grab them one at a time inside a loop, then you need an efficient routine for finding an arbitrary bit. Some processors have an instruction built into them to do this - something to find the left-most or right-most bit set (it's often cast as a problem of counting how many zero bits on the left or right, but it's the same thing.) I'm not sure the instruction is always fast however. There are lots of interesting ways to construct such a routine but it becomes even more elaborate when you have artifically long integers - you must do this 1 piece at a time. Still, I have long considered writing a program this way - just to see for myself if it can be made fast.Some chess programs use the technique to advantage, even on 32 bit computers even though it's faster and more natural on 64 bit computers for Chess. You shold go ahead a build an engine using your ideas. As a group we have developed an almost standardized performance test - see how fast you can generate uniformly random moves by playing a few thousand random games. Compare it with the numbers that have been posted on this group. Your idea is useful if it can be show to be superior in some way to other move generation techniques. It may be superior in speed or some other metric. - Don On Sun, 2007-03-25 at 18:55 +, forrest curo wrote: Since I signed up for this list, I've been receiving all sorts of material about how to test existing programs against one another. Does this bunch ever get around to the merits of various ways of representing the board and arriving at moves? For example, something I suggested the last time I was on a computer go list, back in the 90's: Take an array of 7 64-bit integers... Put the top row of the board into bits 58-40 of the second integer, the next row into the same part of the third integer, so-on until the 7th row fits into bits 38-20 of the first integer (and the 14th into bits 19-1.) Bits 59-40 of the first integer, 18-0 of the 7th integer, are zeroed out (representing rows off the top and the bottom of the board, respectively.) If we're showing the spaces on a vacant board, for example, that's $0eenothing -row 7-row 14 $eee row 1--row 8--row 15 $eee row 2--row 9--row 16 $eee row 3--row 10--row 17 $eee row 4--row 11--row 18 $eee row 5--row 12--row 19 $ee0row 6--row 13--nothing Seven large numbers showing the presence or absence of one condition (in this case, an empty intersection) at each point. Not useful? If you have an array like this, and another like it showing the location of all the black spaces, a few shifts and bitwise logical operations will give you a new array showing all the breathing spaces of all black chains on the board. It takes at least two such arrays to fully represent a go position, with considerable redundancy at that, even more so if you use separate arrays for black stones, white stones, empties--but on a true 64-bit machine, one ought to be able to test for all sorts of local configurations really FAST. Even on the plain old 32 bit pc I was using back when I actually worked on this, I found the representation above was good for quickly detecting captures (etc). These days, considering trying again, still on 32 bits, I'm inclined to use 19-integer arrays for the sake of keeping things simple debuggable. But maybe someone else will find a use for this system--or suggest an arrangement I might find more useful? Forrest
Re: [computer-go] another subject?
Since I signed up for this list, I've been receiving all sorts of material about how to test existing programs against one another. Does this bunch ever get around to the merits of various ways of representing the board and arriving at moves? For example, something I suggested the last time I was on a computer go list, back in the 90's: Take an array of 7 64-bit integers... Put the top row of the board into bits 58-40 of the second integer, the next row into the same part of the third integer, so-on until the 7th row fits into bits 38-20 of the first integer (and the 14th into bits 19-1.) Bits 59-40 of the first integer, 18-0 of the 7th integer, are zeroed out (representing rows off the top and the bottom of the board, respectively.) If we're showing the spaces on a vacant board, for example, that's $0eenothing -row 7-row 14 $eee row 1--row 8--row 15 $eee row 2--row 9--row 16 $eee row 3--row 10--row 17 $eee row 4--row 11--row 18 $eee row 5--row 12--row 19 $ee0row 6--row 13--nothing Seven large numbers showing the presence or absence of one condition (in this case, an empty intersection) at each point. Not useful? If you have an array like this, and another like it showing the location of all the black spaces, a few shifts and bitwise logical operations will give you a new array showing all the breathing spaces of all black chains on the board. It takes at least two such arrays to fully represent a go position, with considerable redundancy at that, even more so if you use separate arrays for black stones, white stones, empties--but on a true 64-bit machine, one ought to be able to test for all sorts of local configurations really FAST. Even on the plain old 32 bit pc I was using back when I actually worked on this, I found the representation above was good for quickly detecting captures (etc). These days, considering trying again, still on 32 bits, I'm inclined to use 19-integer arrays for the sake of keeping things simple debuggable. But maybe someone else will find a use for this system--or suggest an arrangement I might find more useful? Forrest Curo San Diego ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
