RE: [computer-go] misconception about game(?)
for example, go books make a big deal about where to extend along the side, or when to play in one corner or another, but the difference between these various moves is usually only a few points. The difference between similar-appearing various moves may well be one of efficiency--and that translates into sente or control of the game. A typical technique of human analysis is to consider the shape of a position: If the same moves had been made in a different order, would all of them be necessary or even justifiable? Good shape normally gives you a stable, highly defensible position with the minimal number of moves and hence the best chance of keeping-or-recovering sente. High-handicap games don't look playable if you think of a handicap position as having given the weaker player territory, which the higher-ranked player must take away... What a handicap actually gives is First Move in many places. A higher-ranking opponent doesn't take away anything tangible that the weaker player possessed; what he takes, repeatedly, is the initiative. And that's enough to add up to a great many points! Forrest Curo This message was sent using IMP, the Internet Messaging Program. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: language efficiency
I'd like to know how well MoGo would have played if you let it think for a week for every move. Probably diminishing returns. Once a series of random playouts has given it a selection of the more significant points to consider, I'd expect move-order, forcing moves, the need to follow a sequence to a stable conclusion to become so critical that any number of pure-random playouts would fall short of giving a proper evaluation of a position. Another matter: I'm very fond of C, because my love-hate relation with computers goes back to the days when it was essential to know where your program was and what it was up to; I'm still happier with systems where I know they're doing pretty much what I asked for. But for go I think I'll need a complex design with multiply-linked lists, which I can do in C, but not without my mind turning to sphagetti-knots for the duration. So Scheme is one of the languages I've been considering, and in the process I stumbled upon a list of programs it was used to write. One of them: GIMP (Graphic Images Manipulation Program). Relevance?--Graphic images of any detail are enormous chunks of data; doing even a simple computation on one of these files has got to require a lot of bit-crunching, which used to be pretty time-consuming even when I was processing low-resolution grayscale photos for a monthly tabloid. I haven't run a direct comparison with GIMP's commercial rivals, but it's impressively fast by my standards... Forrest Curo This message was sent using IMP, the Internet Messaging Program. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] How does MC do with ladders?
It's the approach I believe to be more human-like. Not necessarily the playing style. Human beings chunk. What all this fuss suggests to me is a meta-mc program... You include routines that work out good sequences, as a human would--and then you have the random part of the program include the more promising sequences, where applicable, as if they were individual moves. Forrest Curo This message was sent using IMP, the Internet Messaging Program. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] How does MC do with ladders?
Quoting Álvaro Begué [EMAIL PROTECTED]: On Dec 13, 2007 2:28 PM, Forrest Curo [EMAIL PROTECTED] wrote: It's the approach I believe to be more human-like. Not necessarily the playing style. Human beings chunk. What all this fuss suggests to me is a meta-mc program... You include routines that work out good sequences, as a human would--and then you have the random part of the program include the more promising sequences, where applicable, as if they were individual moves. You can't do that in two-player games, unless you are convinced that the opponent is forced throughout the entire sequence. Humans do a sort of skinny alpha-beta, automatically narrowing the search by applying constraints based on what they see as possible outcomes. (In the case of a ladder, most of this is searching a long branch one-move wide!) So if an opponent fails to follow the sequence you've expected, he might be on to something you missed, or he may have missed the point of the sequence. An unexpected move thus suggests a pair of local searches, concentrating both on the vicinity of that move and on the vicinity of the expected move. But for a program to do something similar, it does need some way of arriving at an idea of what moves in a certain area could reasonably be expected to accomplish. Seeing where the groups end up in a large number of playoffs might give a hint...(?) Forrest Curo This message was sent using IMP, the Internet Messaging Program. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go]mc analogue
Here is a card game I thought of while considering how to chunk moves based on mc outcomes... It is not in any way equivalent to programming go, but there are significant similarities. You have a deck of 360 cards numbered sequentially. (This is not as complex as go, but the tree of potential moves is going to be of similar size, narrower in places but always extending to 360 moves total. The size could be changed without significantly changing the game, so long as the number is even.) To make a legal move: 1) If your opponent has played a card, and there is a lower card available, you must play a lower card. 2) If 1) does not apply, you can play any card. The game ends when all cards are played, and each player scores the total of the numbers on the cards it has played. A human player can readily analyze the game, seeing that the first player wins with correct play, but loses against correct play if he misses the right first move. Our computer players, however, are to be limited to whatever information they can derive from the final scores at the end of the potential playouts from a particular move. They aren't allowed to read the actual numbers on the cards or count the number of branches resulting from a move, although they can of course distinguish whichever moves they've made in a playout from those the opponent played, and when, as an aid to choosing which moves are better in the sense of working more often against limited-information play. So--How many playouts to find the best line of play against 1) another computer with the same limitations or 2) a human? At what point in the game does it become possible for the poor artificially-handicapped program to find a winning line, if one remains? If two programs play one another under these limitations, it is obvious that some moves will be more likely to win than others, depending on which cards have been played. Some responses, while falling short of ideal play, will still leave better odds of the opponent missing whatever winning lines they've left open, and will thus be objectively better than others. Can an mc player recognize them? At what point? Forrest Curo This message was sent using IMP, the Internet Messaging Program. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] The global search myth
Relatively speaking chess eval of adding piece values together and doing nothing else is far closer to optimal evaluation function that what is currently available in Go. A GOOD go evaluation function probably needs to incorporate lookahead... Through most of the game, the difference between a dead group and a live group can only be distinguished by answering What happens here if I do THIS? And to make that investigation supportable, you need a good move-evaluator. A pattern-recognizer with a taste for 'good shape.' In other words, all these functions are interdependent and virtually need one another just to define (in an operational sense) what they need to consider! Forrest Curo This message was sent using IMP, the Internet Messaging Program. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Intelligence
Intelligence is the ability to adapt or learn. I would believe neural network is not a proper way on learning GO, as too many nodes would be needed for patterns, and storage and training may not be feasible. But a variant on the neural network idea could work. (If these cells are sending a bit to one another, there is no additional overhead in sending a 32-bit pattern, not much in having different cells process the received patterns differently.) The normal ways of training a network to recognize a human-generated set of correct responses aren't applicable; but you can always form a list of which cells were involved in a particular move, and use it to raise thresholds, reduce sensitivity to particular inputs, etc. The problem someone here reminded me of yesterday--What subgoals can a program readily train itself to recognize? Generate some ~180 moves, then see whether they led to a win, and reward/discourage itself retroactively? Clumsy! So--How do most living beings do it? Pleasure/pain. Animate beings have internal indicators of How am I doing? When these are high, there's a tendency to repeat whatever one was doing, try more, get adventurous; if low, to STOP THAT! (Since THAT may not be well-defined, pain/discouragement can be taken too far, but it does offer the best chance of not repeating the situation.) The problem is, how to recognize when a program should 'pleasure itself'? Or suffer? Some kind of evolutionary scheme for generating good evaluators? We can't just indiscriminately let a program encourage whatever pathway leads it to encourage itself; it might decide it doesn't need to play that silly game! Ahhh! Maybe some long-term setting based on wins/losses, weighted toward recent games? When this is high, continue to moderately encourage moves/positions that the evaluator likes-- when low, kick the evaluating net/subnet until it either dies or gets less indiscriminatingly encouraging? Forrest Curo ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Sylvain's results
In [ext]The Theory Practice of Go, Korschelt describes an experimental 21x21 goban that he constructed and turned over to his Master, Murase Shuho, for testing. Anyone who wants to try this can play email-style games on dragongoserver.net -- up to 25X25. Forrest Curo ___ computer-go mailing list [EMAIL PROTECTED] http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] professional knowledge
The gap between a professional and, say, a 1-dan amateur is all to do with tesuji knowledge, life/death knowledge, and (to a lesser extent) tactical reading skill, accurate endgame counting and joseki knowledge. All except joseki-knowledge is board-size independent. There's also what you might call the meta-knowledge of joseki: Which joseki will accomplish worthwhile goals for me in this position vs which joseki might (while giving perfectly balanced results in a generic corner) entirely fail to make the best of this situation? That is a separate type of knowledge, as in the proverb Learn joseki, lose ten ranks in strength. The chief difference between a 9X9 game and a 19X19 is in the demands the larger board makes on our _strategic_ reading ability. And that is not merely another board-size-dependent skill, among many. That is the most significant difference between a competent player and a strong one. Forrest Curo San Diego ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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/
