Re: [Computer-go] Indexing and Searching Go Positions -- Literature Wanted
At 07:07 AM 9/17/2019, Brian Sheppard via Computer-go wrote: >I remember a scheme (from Dave Dyer, IIRC) that indexed positions based on the >points on which the 20th, 40th, 60th,... moves were made. IIRC it was nearly a >unique key for pro positions. Correct, but it's only useful for game recognition, not for any other kind of search. It was intended for the pre-digital "what game is that" problem for printed games. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Crazy Stone is back
At 06:31 AM 3/5/2018, valky...@phmp.se wrote: >My guess is that there is some kind of threshold depending on the relative >strength of MC eval and the value function of the NN. My experiments suggest it's better to train with much longer MCTS time than will be used in actual play, so the MCTS values that are the input to training are as good as possible. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] MCTS with win-draw-loss scores
The exact meaning of the result MCTS returns is irrelevant. The net should just learn it. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] difficult things for alphazero
At 08:05 AM 12/8/2017, Jim O'Flaherty wrote: >Dave, > >To whom is the "your" in your first sentence referring? There is no context >from which to derive to whom you are speaking. Sorry, it was "your" reference to Abchij, but I intended it to be about any attempt to make games that are difficult for alphazero. The domain of games is so much smaller than the domain of hard problems. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] difficult things for alphazero
Without reference to your specific ideas for games that might be difficult to solve, I wonder where these games fit on the human playability scale. The things we find acceptable as games are in a pretty small domain, which lies between the things that are trivial and the things that are too hard. There are lots of very hard problems, which are not games, which I bet the owners of Alphazero are interested in attacking next. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Learning related stuff
My question is this; people have been messing around with neural nets and machine learning for 40 years; what was the breakthrough that made alphago succeed so spectacularly. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Is MCTS needed?
While MCTS works "better" in games with a forward direction, it eventually converges to the same answer as alpha-beta in any game. The general architecture is to set a maximum depth, and use a suitable evaluator at the leaf nodes. I haven't done detailed studies, but there is definitely a space where (for example) a 30 second MCTS with a depth limit of 20 ply will outperform a progressive-deepening alpha-beta that is allowed 30 seconds. Another advantage of MCTS is that it's easy to run multiple threads, which is not true of alpha-beta. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Is MCTS needed?
While MCTS works "better" in games with a forward direction, it eventually converges to the same answer as alpha-beta in any game. The general architecture is to set a maximum depth, and use a suitable evaluator at the leaf nodes. I haven't done detailed studies, but there is definitely a space where (for example) a 30 second MCTS with a depth limit of 20 ply will outperform a progressive-deepening alpha-beta that is allowed 30 seconds. Another advantage of MCTS is that it's easy to run multiple threads, which is not true of alpha-beta. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Alphago Zero special circumstances
I wonder how alphago-0 treats the menagerie of special positions, such as bent 4 in the corner, thousand year ko, rotating ko, etc. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Alphago Zero special circumstances
I wonder how alphago-0 treats the menagerie of special positions, such as bent 4 in the corner, thousand year ko, rotating ko, etc. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Possible idea - decay old simulations?
The tree built by MCTS is very unbalanced - some branches are explored more thoroughly than others. Tweaking the algorithm to favor the newer results might result in an overall improvement, but it also would be subject to all the pitfalls of partially or unevenly evaluated trees. This is especially true if the creation of new nodes is stopped due to memory limitations. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Possible idea - decay old simulations?
The tree built by MCTS is very unbalanced - some branches are explored more thoroughly than others. Tweaking the algorithm to favor the newer results might result in an overall improvement, but it also would be subject to all the pitfalls of partially or unevenly evaluated trees. This is especially true if the creation of new nodes is stopped due to memory limitations. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] SGF
Character encoding (usually UTF8 these days) ought not to be part of the standard, it ought to be up to the containing file to describe the encoding at that level.Likewise, nothing in the standard ought to require support for particular character sets. Rather, if a sgf record contains an unsupported character set, it will fail at the "reading" phase, independent of the actual contents of the file. I've used sgf as a general format for more than 70 different games, as well as Go, and I only treat it as a rough guide. I use a generic read/write process that doesn't care about the content, and any sensible user of the "standard" ought to do likewise. The details of what properties exist and how they are used is always going to be a negotiation between content originators and third party consumers. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Auto Go game recorder
Baduk cap does a reasonably good job of recognising where the stones are, but that's a far cry from recording a game as it progresses. It doesn't do life and death of the endgame position. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] DarkForest is open-source now.
At 11:31 AM 6/10/2016, uurtamo wrote: >Compiler no workie? ;) Lazy. Lots of junk to install and get working. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] DarkForest is open-source now.
Now if someone would post a binary that would just run on suitable hardware. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] DarkForest is open-source now.
Now if someone would post a binary that would just run on suitable hardware. ___ 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
A lot of what passes through this list would be just noise on a forum, but it's good to have a public face for summaries, announcements, and items with crossover interest to other games. ___ 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
I was recently working on assigning final scores to completed games, using the large data set from Badukmovies.com. My observation is that the size of the data set (50,000 games) is not large enough to get good coverage of unusual situations occurring in real games. There's a definite need for a curated collection of atypical but interesting games, probably manipulated to explore the boundaries between interesting and normal. ___ 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
I was recently working on assigning final scores to completed games, using the large data set from Badukmovies.com. My observation is that the size of the data set (50,000 games) is not large enough to get good coverage of unusual situations occurring in real games. There's a definite need for a curated collection of atypical but interesting games, probably manipulated to explore the boundaries between interesting and normal. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Seldom, but not alarming
>Can you tell us the rules of the game? Maybe they help to explain the >phenomenon. The game is https://boardgamegeek.com/boardgame/149910/six-making The most unusual thing I see in the UCT tree is that at all the moves seem to be evaluated about the same, right up to the point where wins start appearing; so the UCT tree is unusually uniform. The typical branch factor is 40 or so, and all 40 moves tend to be have about the same number of visits and win rate. Currently, the best way to cope with the problem is to simply stop the run when the node limit is hit. It's not a practical problem either, since the robot is devastatingly good compared to human players, even with very short time. If possible, make a PDF of your paper available. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
[Computer-go] alarming UCT behavior
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
At 10:59 AM 11/6/2015, Gonçalo Mendes Ferreira wrote: >That doesn't seem very realistic. This is with a well tested framework that's been used for 20+ games. Whatever the ultimate resolution, the counter intuitive result that triggered it stands alone; longer think times give worse results. I haven't seen this in any other game - I routinely start with a quick playing robot, and make a better robot by cranking up the time allowance. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] alarming UCT behavior
>But you are stopping right at the atari, and then pile on playouts that make >it seem work... Yes, something like that may be the situation that turns the result. Suppose the tree stops at a point where there are two moves, a blunder that leads to a quick end, and another move which leads to an inconclusive continuation. If the tree can't grow, then random playouts will take the "blunder" branch 50% of time, whereas if the tree were allowed to grow the non-blunder branch would quickly dominate. Overall, once the tree is frozen, some percentage of the leaf nodes will be permanently giving bad feedback. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] alarming UCT behavior
>I have seen this exact behavior when first experimenting with long thinking >times in Pachi. When you stop growing the tree, the algorithm degenerates to >"delayed" single-level Monte Carlo along the principal variations, with all >the MC-without-tree weaknesses. The pathology definitely depends on the nature of the situation at the leaves. For example, one of my 'bots plays hex, and that robot plays so quickly that the memory limit is reached almost immediately. Yet, continuing to run simulations still improves the results. An experiment I just ran at 15 seconds per move, hit the memory limit in less than 1 second. If you stop the run after 1 second, the result is a lot weaker than the full 15 second run. My take-away from this is that small, reasonable-sounding choices can have huge unintended and unanticipated consequences. Not really news to anyone using UCT, but easy to forget. ___ 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?
How about handicapping the hardware based on time. Programs running on more powerful hardware would get less time. On the other hand, improving the software includes making use of more powerful hardware. Handicapping (or banning) powerful hardware would discourage that. On third hand, development teams get the most information out of competitions if the race is close, so it's in their interest to not crush competitors. 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. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Programme NAO to play Go and talk about it
Maybe, maybe not. Current research in volition and conscious choice indicates that conscious choice is actually an after the fact explanation of decisions based on unconscious processes. I found this video about how research into visualizing neural networks led to big improvements, by showing up areas where the current networks were weak. https://www.youtube.com/watch?v=ghEmQSxT6tw ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Arimaa bot notably stronger
My reading of the material currently available is that the big advance was to forward prune a lot of moves based on simple utility metrics. Moves that don't do something are thrown out. A reasonable idea, but the utility metrics are specific to arimaa; and even for the general idea, it's hard to see analogs for Go. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] CGOS future
It's easy to get 20+ ppl saying OMG I want to help. But I need at least 1-2 more core devs outside me, especially if I'm working in a language outside my zone. All I can say is, if you need 1-2 outside collaborators, you better have a plan B. Everyone dances to their own tune, and no one wants to follow anyone else's directions unless there's an agreed higher calling (such as getting rich, which is clearly not applicable here). ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] CGOS future
Is anyone else bothered the line endings of cgos messages are being transformed, which makes everything mash onto one long line on my mail reader ? ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] house robot for Boardspace
I'm planning to add Go (for human players) to Boardspace.net soon, and I would like to have at least a minimal house robot to play on small boards. It's absolutely required that the bot be written in Java. Other than that, the main requirement is cooperation to integrate the bot into the game framework. The benefit to authors is you'll games with real human players, and the benefit of a great GUI to use in development. Not an exclusive offer - I can accommodate several robots. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] fast + good RNG
Anyway, it's very easy to make a fast PRNG these days. A couple words of caution about hacking PNRG. Back in the stone age of computing, some mavens from the triple-i movie group cooked up a galaxy simulator which generated pictures of spiral galaxies based on a numerical model. The capability to make pictures was rare at the time. The pictures sucked. After lots of hunting for flaws in the model, and tweaking it, the real cause for the poor quality was determined to be that fortran's random numbers weren't very good. Substitute a better PRNG, and beautiful pictures emerged. -- On a similar note, working with a UCT robot for a blokus clone at boardspace.net, I found that tiny changes in the way PRNG's were used had measurable effects on the quality of play. Not necessarily better or worse, just different. -- So if you're going to hack the PRNG, you should retain the ability to use a gold standard PRNG instead of your faster-better-cheaper model, and you should use it once in a while, just to be sure you're not introducing hidden flaws. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] sgf reader/editor/write in java?
Read and Write is easy, I have some classes I use for all my games that I've distributed several times. Edit implies a full gui, which is a little more complicated. I have a fairly primitive board widget I've distributed in the past. If your goal is a fully featured go gui, with replay and review capabilities, you could start with Jago. With about 10 minutes work, you could convert the hex board for boardspace.net to a go board. The advantage of this approach is that you'd automatically have a pretty functional editing package. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] cgos.computergo.org down?
At 01:14 PM 3/1/2015, folkert wrote: Hi, It looks like cgos.computergo.org is down? the server has moved back to cgos.boardspace.net ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Teaching Deep Convolutional Neural Networks to Play Go
You don't need a neural net to predict pro moves at this level. My measurement metric was slightly different, I counted how far down the list of moves the pro move appeared, so matching the pro move scored as 100% and being tenth on a list of 100 moves scored 90%. Combining simple metrics such as 3x3 neighborhood, position on the board, and proximity to previous play, you can easily get to an average score of 85%, without producing noticeably good play, at least without a search to back it up. http://real-me.net/ddyer/go/global-eval.html ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
[computer-go] Re: Open source real time Go server
(i) IGS is derivation of NNGS, which is free software (GPLv2)! It has even seen some slight development in past few years. I don't think that's correct - NNGS was a functional copy of IGS created by duplicating the published (telnet based) interfaces. It eventually was open sourced before it died. (ii) NNGS might be used as possible base of a modern go server. The obvious advantage is that _right now_ you have something that you can (in theory) compile, start, connect to and chat and play go on (!) and you can evolve things from here. NNGS is alive and well as software, but no one is actively running a copy for human use as far as I know. Boardspace is still running a completely ignored copy, intended to be used by robots. http://boardspace.net/nngs/ If one wanted to develop a client for the blind, you could certainly start with a NNGS clone as your target server, and one of the open source IGS clients as your client. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] OT: AI article I found interesting
At 10:12 AM 10/24/2009, Joshua Shriver wrote: Came across this today, and since this is also an AI oriented list thought some of you might enjoy it too. http://www.techradar.com/news/world-of-tech/future-tech/the-past-present-and-future-of-ai-643838http://www.techradar.com/news/world-of-tech/future-tech/the-past-present-and-future-of-ai-643838 I won't believe it even if I see it. Google Mechanical Turk ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Rating variability on CGOS
In any rating scheme, who you play can be as important as how well. This is especially true for small groups. Suddenly adding or dropping a strong player will certainly cause all the other player's ratings to shift. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: self atari
It's easy to construct self-atari of unlimited size that both can occur and should be played, if the capturing move that follows the self-atari is then recaptured in a snapback. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Dynamic komi in commercial programs
If you are in a lost position, good play is play that maximizes the probability of a turnaround, which is quite different depending on how far behind you are, and for what reason. If the status of all the major groups is solid, then concentrating on tactics which can gain a few points reliably might be the right thing. On the other hand, if the status of some groups is less than immutable, then focusing on changing their status favorably might be correct. It's hard to see how shifting Komi will influence the style of play in this direction. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Cgos redesign
My $0.02 The choice of language is mostly arbitrary. CGOS is really two separate programs: (1) an I/O multiplexer that manages the clients connections and detailed communication, (2) a scheduler/planner/recorder that manages the overall operation of the site. I would definitely separate those two, so the scheduler can be developed and tweaked independently of the client manager. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Problems with CGOS
So I believe this is a design flaw in CGOS itself. I wrote CGOS without having had any experience writing servers. If there's a problem with larger databases, perhaps it can be fixed by adding the right indexes to the sql database. If you add a little time monitoring code around your queries to determine which are slowest, you may be able to devise a 1 line fix, by added an index to the schema. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re:verifiable claims
And somehow I don't ever see comments anywhere suggesting that this could be a problem. So what I'd like to know is: is this so trivial that no one ever mentions it, or are the heuristics that programs use to terminate playouts so obscure that they are too embarrasing to mention? Completely solving a game by search is a special case, because you're only interested in terminals where the game is over. In the more common case, you're only searching to choose the next move, with no guarantee that it is best. Such playouts are typically depth limited, but strategies for deciding exactly where to stop can be quite complex. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: verifiable claims
I've written dozens of games with alpha-beta searches, so I think it's fair to say that I have a basic understanding of the process. Your description is correct but incomplete. Alpha beta is good at eliminating lines of play once a strong outcome is known somewhere in the tree, but much weaker before that. If a big capture occurs at ply 30, but the shortest win is at ply 60, you still have to explore an enormous number of silly variations as you iteratively deepen between ply 30 and 59. The fact that you don't need to explore continuations of the silly moves past move 59 is cold comfort. The other half of the bad news is that while only the best move of the winning lines needs to be explored, generally all of the possible responses have to be explored. So the tree actually explored tends to be narrow for the winning line, but very wide as all possible responses to the correct move are explored. In the case of a big capture being the correct move, pitching into every one of the captured spaces will have to be explored. Alpha beta engines which do not use inadmissible (but probably valid) tricks waste exponentially more time than those that do. It's quite possible that 5x5 is on the sweet side of the equation with today's available CPUs, but at some point not much further away, you have to accept results that you believe but can't prove, as better than no result at all. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: verifiable claims
Some lines of play involving large captures will effectively never terminate, even with superko rules in effect. I doubt it is possible to eliminate all these non-terminating lines of play in any way that is provably correct. .. So while claims of solution by exhaustive search might be very convincing, I doubt they can ever be proved. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: verifiable claims
You can just prove that you can make a large-enough chain that is unconditionally alive. I believe that's what Erik did. In practice, you cannot do an exhaustive search using superko rules because then hash table scores cannot be used. I don't think you can always do that. For example, if white is capturing a chain of size 30, how can you prove that black can never profit by continuing inside that 30 space void. In fact, in many cases you can demonstrate that he should. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: verifiable claims
At 06:31 PM 5/22/2009, David Doshay wrote: there are no chains of size 30 on a 5x5 board, I'll concede for a 5x5 board, but I think my point is valid for sufficiently large boards, probably 7x7. Almost any strategy other than playing out all legal moves involves a lot of hand waving that is unlikely to be accepted as a proof. There are just too many cases where a pitch inside a captured space has global effects. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Implications of a CPU vs Memory trend on MCTS
Storing an opening book for the first 10 moves requires 331477745148242200 nodes. Even with some reduction for symmetry, I don't see that much memory becoming available anytime soon, and you still have to evaluate them somehow. Actually storing a tree, except for extremely limited special cases, is not even conceptually possible, and doesn't save much time. Consider that if you store the tree you saw at the previous move, by the time you get to use the stored tree 99% of it is useless because your opponent chose his move. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Implications of a CPU vs Memory trend on MCTS
At 02:13 PM 5/12/2009, Michael Williams wrote: Where does your 99% figure come from? 1/361 1% by endgame there are still easily 100 empty spaces on the board. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Implications of a CPU vs Memory trend on MCTS
At 02:13 PM 5/12/2009, Michael Williams wrote: Where does your 99% figure come from? 1/361 1% by endgame there are still easily 100 empty spaces on the board. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Implications of a CPU vs Memory trend on MCTS
An essential feature of monte carlo is that it's search space is random and extremely sparse, so consequently opportunity to re-use nodes is also extremely sparse. On the other hand, if the search close to the root is not sparse, my previous arguments about the number of nodes and the number of them that will continue to be useful still apply. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [personal] Re: [computer-go] Re: Implications of a CPU vs Memory trend on MCTS
I assume Dave Dyer does not understand alpha beta pruning either, or he would not assume the branching factor is 361. The branch at the root is about (361-move number) - you have to consider all top level moves. A/B only kicks in by lowering the average branching factor at lower levels. If you're trying to save and reuse trees to reduce work, alpha beta makes most of the saved nodes useless for anything outside the principle variation. This is precisely because the nodes were mostly not fully explored, and all you know (from the previous evaluation) is that this node is better or worse than some other, now-irrelevant branch. I did a lot of work trying to reuse trees for iterative deepening of alpha-beta searches. It required a lot of bookkeeping and a lot of memory, and it didn't turn out to be a good strategy even for small searches where the memory was essentially cost free. I suppose it's possible there's something fundamentally different here, but you ought to think carefully before investing in terrabyte memories. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Implications of a CPU vs Memory trend on MCTS
If I use persistent storage and do that search again in another game, I can start exactly where I left off and generate 50,000 more nodes. It will be the same as if I did 100,000 nodes instead of 50,000 nodes.Or put another way, it will be the same as if I spent 20 seconds on this move instead of 10 seconds. Sure, but except for openings you'll never reach the same position position in another game unless the players are deliberately copying their play. Consider move 20 (for example). If you saved every move 20 node you ever encountered, how often do you think you'd encounter a duplicate from a different game, such that you can either avoid an evaluation, or improve your knowledge of that position by studying it a bit more. I contend it is a vanishingly small percentage. -- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Implications of a CPU vs Memory trend on MCTS
But then MCTS is invalid. The point is that you do spend time learning that these nodes are not relevant, so you might as well try to remember that. It is invalid. It's just a heuristic that is working within the current domain. If you are playing a game of chess and fall for a trap, do you consider it silly to try to remember this for the next game? The point is that if your opponent wanders into a space you did not consider, you still have to know how to respond. What clever humans recognize as the same trap is actually just one of zillions of similar positions that will be flooding your database of known positions. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Berlekamp lecture on mathematical Go
Highly recommended http://www.youtube.com/watch?v=EjrvrH1bKIwfeature=PlayListp=2C02F6B33145E762index=0playnext=1Mathematics and Go by Elwyn Berlekamp ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] cgos: Donn Daily?
Donn, your email at d...@mit.edu is bouncing. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: static evaluators for tree search
While your goal is laudable, I'm afraid there is no such thing as a simple tree search with a plug-in evaluator for Go. The problem is that the move generator has to be very disciplined, and the evaluator typically requires elaborate and expensive to maintain data structures. It all tends to be very convoluted and full of feedback loops, in addition to the actual alpha-beta which is trivial by comparison. If you look at GnuGo or some other available program, I'm pretty sure you'll find a line of code where the evaluator is called, and you could replace it, but you'll find it's connected to a pile of spaghetti. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: static evaluators for tree search
Do you mean that the evaluator might be used during move ordering somehow and that generating the nodes to expand is tightly coupled with the static evaluator? That's the general idea. No search program can afford to use a fan-out factor of 361. The information about what to cut has to come from somewhere. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: static evaluators for tree search
Do you mean that the evaluator might be used during move ordering somehow and that generating the nodes to expand is tightly coupled with the static evaluator? That's the general idea. No search program can afford to use a fan-out factor of 361. The information about what to cut has to come from somewhere. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: static evaluators for tree search
This is old and incomplete, but still is a starting point you might find useful http://www.andromeda.com/people/ddyer/go/global-eval.html General observations (from a weak player's point of view): Go is played on a knife edge between life and death. The only evaluator that matters is is this stone alive, and there are no known proxies that will not fall short a significant amount of the time. If you fall short once or twice in a game against a competent player, you will lose. General strategic considerations will play you false every time. -- Notwithstanding the above, improving general considerations will improve play, but not much. It's all about the minutia of the situation. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: remote time measurement
At 12:59 AM 2/4/2009, David Fotland wrote: What do you mean by operator at remote end? In my case, the program was running on a cluster at Microsoft in some computer data center. There was no operator at Microsoft. The cluster was operated from Beijing through a remote desktop. The operator was at the contest site. In that case, the operator is watching you. The goal is to certify that the human putatively responsible for the program is behaving consistent with the competition, not unplugging cables or feeding in moves from a hidden 9 dan. It wouldn't prevent a deliberate attempt to defraud, but it would add a significant amount of complexity. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: remote time measurement
My theory is that the organizers of tournaments with remote participants could appoint official observers, to observe the operators at the remote end of connections. Not foolproof, but simple and doesn't interfere with the conduct of the tournament. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Is computer Havannah welcome here?
There's already a havannah section on this game programming forum: http://www.grappa.univ-lille3.fr/ -- which could use an influx of traffic. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Hardware limits
Lets look at it another way - no one would care what hardware you choose to use, unless you win. So at the very least, you ought to be able to use arbitrary hardware until it becomes established that only that class of hardware can win. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Hardware limits
I think general hardware limits are good, because they will permit more teams to be competitive without altering the nature of the competition. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: hex robot
At 01:52 AM 11/27/2008, Denis fidaali wrote: ... But what really lacks (or i wasn't able to find anyway) is a strong community like there is for go. A CGOS equivalent. A GTP equivalent. A Gogui equivalent. A Kgs equivalent. I don't think there's a match between your goals and what boardspace wants, but you ought to discuss cloning and adapting CGOS/GTP for Hex with Don. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] RE: hex robot
Permit me to play the skeptic here; I think you're going about it absolutely backwards - unless you already have a strong algorithm which depends on 128 bit rotations, and only lack an efficient hardware engine to run it on. If your idea of fun is to really feel the bits squishing between your toes, by all means do, but I don't think it's likely you will simultaneously make advances in Hex theory or practice. At 12:19 AM 11/27/2008, Denis fidaali wrote: My current plan is to tackle directly the power of x86-64bits architecture. Because it's now quite well represented. And there is this larrabee project that may get out in one or two years (48 x86-64bits processors). So my true goal is to try and see what i can do with my quad Q9300 2.5Ghz running a 64 bits linux. Obviously one need a bit of work before being able to hope to achieve something with assembly. etc... ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: flash crowd from TV
That's impressive, especially considering the fairly long search path between Go and igowin. It happens. One day recently I was idling at boardspace.net, when in the course a few minutes the site was overrun by about 30 guests, all speaking German and wanting to play Hex. It turned out that A Beautiful Mind was showing on German TV. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: hex robot
At 01:31 PM 11/26/2008, Denis fidaali wrote: Speaking of hex ... I really think it would be a nice intermediary game before tackling the complexity of go. Do you know of any good community (and protocol equivalent to GTP) where i could start to look for submitting a bot ? There are a couple of pretty decent programs and some nice underlying theory. Also a perfect play bot for a small board. I would start at the Hex wiki page to research them. A credible Hex bot is on my wish list for Boardspace. The one I wrote is laughably weak, but it will be a significant effort to write a better one. If you're willing to work in Java and within the constraints of a realtime web site, lets talk. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Another enhancement to AMAF
Here's a chance to share an amusing and illustrative anecdote. I was working on optimizing Goodbot, a program that plays Tantrix, and because of the nature of the game, the only way to really qualify an improvement is to run many test games against a standard opponent. At one point, I was making nightly test runs of a few hundred games, with slightly tweaked parameters and underlying tweaks to the algorithms, always seeking to improve over the reference standard. At one point, I discovered that due to some temporary code accidentally left in place, I had actually been running exactly the same code for about a month, and all perceived movement in better or worse directions was only due to random fluctuations. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Another enhancement to AMAF
Here's a chance to share an amusing and illustrative anecdote. I was working on optimizing Goodbot, a program that plays Tantrix, and because of the nature of the game, the only way to really qualify an improvement is to run many test games against a standard opponent. At one point, I was making nightly test runs of a few hundred games, with slightly tweaked parameters and underlying tweaks to the algorithms, always seeking to improve over the reference standard. At one point, I discovered that due to some temporary code accidentally left in place, I had actually been running exactly the same code for about a month, and all perceived movement in better or worse directions was only due to random fluctuations. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: OT: Harder than go?
I think the question is largely meaningless, because few games have been studied by humans (or human computer programmers) with the depth and intensity that has been achieved for games like chess and go. In general, games with many choices and no obvious strategies are good for people and bad for computers. Two examples that fit this paradigm, and have been proposed as examples of hard for computers are Arimaa and Havannah ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Git, any other ideas?
For those of you who use windows, I highly recommend tortoise cvs and tortoise svn, which map access to whichever repository you prefer into an incredibly useful and intuitive interface piggybacked on windows explorer. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Git, any other ideas?
For those of you who use windows, I highly recommend tortoise cvs and tortoise svn, which map access to whichever repository you prefer into an incredibly useful and intuitive interface piggybacked on windows explorer. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: reference bots testing.
I suggest you add an identical RNG for testing purposes, which you will know is identical in both implementations even if it is not ideal. Run a test with a seeded random sequence which should provide identical playouts. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Disputes under Japanese rules
The formalized rules are the tortured details I referred to. I've played thousands of games of Go, and I've never even seen any of those versions of the rules. The Japanese rules I refer to are the informal procedures I use every time I play, both to estimate the score during the game, and at the end. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Disputes under Japanese rules
Japanese: bad. I don't think this is the case at all. The Japanese rules are just a human optimization, to avoid having to make the last 100 meaningless moves, and still arrive at the correct score with a minimum of extraneous manipulation. The tortured details, while not elegant, rarely matter. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Some thoughts on the event in Leksand
This was typically to pick up my queen, change its colour, and capture my rook with it. Now there's a feature that would make a tournament interesting... If this appeals to you, try Martian Chess or Shogi ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: What's happening at the European Go Congress?
I think the result computer in hopelessly lost position resigns. is much more satisfactory than computer in hopelessly lost position wins by playing 100 additional pointless moves I think a human who used this tactic in a tournament situation might win the trophy, but would be unable to show his face again. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: What's happening at the European Go Congress?
I think the result computer in hopelessly lost position resigns. is much more satisfactory than computer in hopelessly lost position wins by playing 100 additional pointless moves I think a human who used this tactic in a tournament situation might win the trophy, but would be unable to show his face again. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Program don't start playing on CGOS
I'm really very weak on networking so I'm not sure what I'm actually reading or whether this fix needs to be applied on the server end or the client end. Any ideas is this is relevant? You also have the same problem, but with much less real information, if the client end end of the connection is bridged by a router, with is pretty common. I'm absolutely certain that ordinary consumer routers are not very reliable. They have very limited memory, and arbitrary and undocumented policies for maintaining their connection tables. Sometimes power cycling them helps. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Program don't start playing on CGOS
I'm really very weak on networking so I'm not sure what I'm actually reading or whether this fix needs to be applied on the server end or the client end. Any ideas is this is relevant? You also have the same problem, but with much less real information, if the client end end of the connection is bridged by a router, with is pretty common. I'm absolutely certain that ordinary consumer routers are not very reliable. They have very limited memory, and arbitrary and undocumented policies for maintaining their connection tables. Sometimes power cycling them helps. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: mogo beats pro!
I watched all the games, and I must say, mogo performed really badly at the blitz games, and quite a bit better at the 1-hour game. I'd still take any claims of dan level play with lots of salt. My take-away from watching the match is that blitz performance wasn't at all representative. A human playing blitz games might do 90% as well as at a full length game, whereas mogo's performance looked like it scaled more linearly. I also wonder how much playing with a 9 or more stone handicap affected it's apparent strength. It's an awful lot easier to appear competent when you start with 9 stones. It looked to me like mogo got totally demolished any place the pro concentrated his attack, except in the lower-right where the pro was caught being careless. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Java SGF Parser
1) Does anybody know of a good Java SGF parser out there? I have one I've used for many types of games, including Go. I've used it to represent large collections with no problems. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Java SGF Parser
1) Does anybody know of a good Java SGF parser out there? I have one I've used for many types of games, including Go. I've used it to represent large collections with no problems. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: linux and windows
Of course C can be more or less platform independent if you take some care. Purely for engine code, that's true. Standard windows has APIs that are nearly compatible with xxux for command line initialization and ordinary file and network operations. If your program has ANY gui at all though, you're pretty much screwed. Mac Windows and Linux GUIs are about as far apart as any three platforms can be. There are lots of compatibility solutions, including your choice of platform independent languages; but they all create essentially a fourth platform that you have to target, and once again, you're screwed unless you started that way. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: My experience with Linux
The thing that really kills multiple platform programs are GUIs. Unless your GUI is born expecting to be cross platform, you're pretty much screwed. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] off topic: Tobacco
By the way, has anyone seen the Philip Morris commercials? I believe they were forced into this as part of the extortion by the state attorneys general. It's Penance for illegally targeting young non-smokers with Joe Camel, and promoting their products while denying that they were dangerous to your health. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: komi argument = silly
To a first order approximation, would changing the komi change the rankings? Presumably, programs are playing the same number of games as black and white, so any unfair advantage or disadvantage black has would balance out. Komi only matters when there is only one game between a pair of opponents. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: 19x19 Study
At 11:44 AM 1/31/2008, David Doshay wrote: That is correct. It is my understanding that the Intel machines can compile to a universal binary that will run on the G5 machines, but we have not verified that. I trust that it works, but have no idea if there is an efficiency hit. Universal binaries just contain two sets of object code. There's no effeciency hit, but your program does need to be aware of potential big endian issues because the same binary might be run on two platforms with different byte orders. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: 19x19 Study
At 11:44 AM 1/31/2008, David Doshay wrote: That is correct. It is my understanding that the Intel machines can compile to a universal binary that will run on the G5 machines, but we have not verified that. I trust that it works, but have no idea if there is an efficiency hit. Universal binaries just contain two sets of object code. There's no effeciency hit, but your program does need to be aware of potential big endian issues because the same binary might be run on two platforms with different byte orders. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: update on networking from phils with new CGOS configuration
It's interesting to look at a graphic plot of a traceroute to see there the actual delays are. I use a program called pingplotter for this, but there are many such programs. Be warned though, that seeing a potential problem only leaves you feeling helpless, since there is typically nothing you can do about it. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Please have your bot resign, for your own good
CGOS uses Chinese scoring with play-outs so that we can get fully automated scoring with no chance of errors. No chance of errors is vacuously true. Errors, if any, were made in the playout leading to the final state. There can be score differences compared to what would have been Japanese score, ranging from zero to extremely large, depending on how correctly the playout was done. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: unconditional life and death
The standard one is Benson's algorithm http://senseis.xmp.net/?BensonsAlgorithmhttp://senseis.xmp.net/?BensonsAlgorithm The standard caveat is that this algorithm alone is very weak - it typically applies to zero stones on a position played out using Japanese rules. But you have to start somewhere. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: unconditional life and death
The standard one is Benson's algorithm http://senseis.xmp.net/?BensonsAlgorithmhttp://senseis.xmp.net/?BensonsAlgorithm The standard caveat is that this algorithm alone is very weak - it typically applies to zero stones on a position played out using Japanese rules. But you have to start somewhere. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: unconditional life and death
There's a sort of hierarchy of life-and-death methods, for which Benson's algorithm is the base. My status database is next above that, but it is actually a lookup table based on a problem solver, such as Wolfs or mine. The unique thing about the database is that it could be dropped in to a program which was prepared to provide the inputs it requires. Thomas and I compared results and cross validated our problem solvers back in the day, so for the set of positions both solvers accepted, very similar results are produced. My solver was not limited to closed shapes, but his was always orders of magnitude faster. In any case, other than discussing the techniques used, these solvers aren't any use to practical programs - there's no solve module anyone can load and use. Above this level (of solvers which work on very simple positions) there is the problem of applying it to a realistic board position. Much more go-specific knowledge is needed here. I worked some on the problem near endgame, but earlier than that is pretty much unexplored territory, except of course by real playing programs which have to apply some heuristics just to function. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Lisp time
My program was written in lisp, so naturally I concur. I'm not actively using lisp any more, but I will offer various dialects of common lisp as the consensus choice of dialect. My favorite implementation is lispworks. The personal edition is free and ought to be adequate for research. The big caveat for using lispworks is that it's a closed universe - editor, compiler, debugger, GUI are all in the same executable. The integration is great, but the strength is also the weakness if you want to share components with any other language. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Lisp time
At 05:24 AM 12/12/2007, Don Dailey wrote: I've looked into this a bit. My preference would be scheme and it's my understanding that it may be a bit more efficient. If you're worried about efficient use of the machine, stay away from lisp and scheme. Despite the claims of it can be as fast as C, you have to work hard and perform unnatural (from the viewpoint of lisp) acts to get anywhere near there. There are deep architectural reasons why lisp is not as efficient as C when used as directed. Use lisp if you're concerned with promoting efficient use of your brain. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Lisp time
At 05:24 AM 12/12/2007, Don Dailey wrote: I've looked into this a bit. My preference would be scheme and it's my understanding that it may be a bit more efficient. If you're worried about efficient use of the machine, stay away from lisp and scheme. Despite the claims of it can be as fast as C, you have to work hard and perform unnatural (from the viewpoint of lisp) acts to get anywhere near there. There are deep architectural reasons why lisp is not as efficient as C when used as directed. Use lisp if you're concerned with promoting efficient use of your brain. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Lisp time
These are true, but not the underlying problem. The biggest underlying reason is the multiple constraints on memory management; a) since the data is typed rather than the pointers, every chunk of memory has to be self identifying, not just for the garbage collector, but also so (plus a b) can do the right thing. b) since garbage collection can occur, the compiler is strongly constrained about when and where it creates and destroys pointers to data that might be garbage collected. c) the layout of the stack is strongly constrained, for the garbage collector, the exception handling system, and also the return values system; any function can return zero or more values, and may not return at all. d) all array references have be bounds checked. All structure references have to be type checked. Another major pain (from the viewpoint of a compiler) is that any function can be redefined at any time, and can have it's fundamental contract changed. A lot of things might need attention at runtime, depending on what assumptions the compiler built into the code it produced. With clever design, and a few extra declarations, this kind of thing need not be horrendously expensive, but it all adds up. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
