RE: [computer-go] Who's going to the Gifu Challenge?
I was there in 2005, and KCC Igo and Go Intellect were there. http://www.computer-go.jp/gifu2005/English/ Ogaki is very nice, but a little tricky to get to by train. I ripped up the full board search and rewrote it last year so I'll only go if I can get it stable and stronger by then. David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Osgood Sent: Monday, July 09, 2007 11:01 AM To: computer-go Subject: [computer-go] Who's going to the Gifu Challenge? From what I can tell, there has not been a clash of the Go titans since the 2003 Gifu Challenge, which had all of KCC Igo, Haruka, Go+ +, Goemate/Handtalk, Many Faces, GNU Go, and Go Intellect participating. (This was the last public competition for many of these programs.) It seems with the tuning of MoGo and CrazyStone for the full size board and their recent success at the Olympiad, that there is a chance to knock KCC Igo (sold as Silver Star in Japan) from its four year throne. Are any of the Mogo, CrazyStone, and other professional program authors leaving room in their autumn schedules to travel to Ogaki City, Japan for this year's Gifu Challenge? Ian ___ 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] 9x9 games wanted and the next big challenge
I also agree that 9x9 doesn't compare to 19x19. I disagree that it's not interesting. It would be uninteresting if, for instance, someone like you were just as good at the top pro's at 9x9. It stops being interested when it can be mastered.If the top players can always play a perfect game, it's not interesting to them, but probably still interesting to me, and to a lesser extent someone like you who would probably be playing close to perfect if the pro's were playing perfect. There would probably be very little difference in someone like you and a top pro and if you played a game well enough you might get some wins if you were on the right side of komi. But this all assumes the game is almost played out. I don't think 9x9 is. I don't mean that 9x9 is trivial. It's just not very interesting to play for someone who plays go. For example, if I started talking about playing chess on a 6x6 board without rooks and with only 6 pawns, it would still be a nontrivial game, but it's not a game that serious chess players would want to play much. If I put up a server to play this 6x6 chess variant and got a lot of programmers interested in writing programs for it, it's still nontrival, but still not very interesting for chess players. It's a different game. David ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Explanation to MoGo paper wanted.
Hi David, (...) I cannot imagine that progress will be made without a great deal of domain knowledge. Depending on what you exactly mean I disagree. I mean progress by the standard usually applied to computer Go: programs that can beat 1D humans on a full board, and then get better. For me progress meant an improvement, not a goal :-). Anyway, very few months ago almost everyone in this list said that UCT/MC was only suitable for 9x9 Go, which was said not representing the Real Game Of Go, and will never (in near future, or even in far future) do well in 19x19. Today, some UCT/MC based programs, e.g. MoGo, can give 5 stones to gnugo on 19x19 in 30 minutes game, without any additional go knowledge. For me it is an evidence that progress can be made very quickly without great deal of domain knowledge. Why we (by we I mean the all community) could not imagine other improvements? 1D humans on a full board is not so far, contrary as you seem to say... I am less sure that knowledge representation in the classical programs is the right expertise for its representation in the MC playouts. Yes, maybe you are right, I don't know. But I think it is not a bad expertise :-). And also it is a very expensive expertise (in the sense that it takes a lot of time to get). So many thing yet to do! To me it sounds like a good news, don't you think? :-) Cheers, Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] SGF parsing
On 7/10/07, Jacques Basaldúa [EMAIL PROTECTED] wrote: Joshua Shriver wrote: Any help is appreciated, trying to write a parse in C There is free source code for that: http://www.red-bean.com/sgf/sgfc/index.html and GnuGo http://www.gnu.org/software/gnugo/ If you want to do something minimal for testing an engine, you only have to find: board size SZ[] komi KM[] and the moves ;B[];W[] the file should have only one starting ( and one final ) i.e. no variations. If you want to extract a variation from a file that contains many, you can use GoKnot using Save as and the file type Smart Game Format (Current variation only) i.o the default Smart Game Format (All variations) On this note, does anyone know of a collection of strange/unusual SGF files to test a parser against? I have a SGF parser written in javacc (think object oriented lex and yacc, outputting pure java) and while it seems fast I've not really tested it much against corner cases. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Who else uses Hashtables in UCT?
I have no finished a plain vanilla 9x9 Suzie-UCT Version. The UCT-tree is stored in a Hashtable. I am interested who else uses this approach. The reason for using a hashtable was: I was too lazy to implement an explicit tree. At least at 9x9 I have no problem with memory size. In fact there are 2 hashtables, one for the Alpha-Beta and one for the UCT-Version. With the default parameters each version uses 160 MB. A chessprogrammer in Go-Land, part X: I interpreted SuperKo as repetition of position (which seems to be correct, although Stefan Mertin told me, there are numerous versions of SuperKo). I used the Nimzo/Hydra code to detect this. But there is a - not a very subtle - difference between Go and Chess. A move which generates a repetition of position is in Chess legal, in Go it is'nt. But I assumed its legal and had quite complicated and buggy code to handle this case. I did not know how to evaluate it. It came not to my mind, that its just an illegal move and one only has to generate the nextbest one. Stefan Mertin told me the difference several times, but it did not help, only the advice of Peter Woitke, just delete this stupid code, was the right instruction level. Chrilly ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Who else uses Hashtables in UCT?
On 7/10/07, chrilly [EMAIL PROTECTED] wrote: I have no finished a plain vanilla 9x9 Suzie-UCT Version. The UCT-tree is stored in a Hashtable. I am interested who else uses this approach. The reason for using a hashtable was: I was too lazy to implement an explicit tree. At least at 9x9 I have no problem with memory size. In fact there are 2 hashtables, one for the Alpha-Beta and one for the UCT-Version. With the default parameters each version uses 160 MB. I'm not there yet with my rewrite, but I plan to be there again soon. There is immense repetition in positions as the search gets deeper, and it just doesn't make sense to not do hash tables. A chessprogrammer in Go-Land, part X: I interpreted SuperKo as repetition of position (which seems to be correct, although Stefan Mertin told me, there are numerous versions of SuperKo). I used the Nimzo/Hydra code to detect this. But there is a - not a very subtle - difference between Go and Chess. A move which generates a repetition of position is in Chess legal, in Go it is'nt. But I assumed its legal and had quite complicated and buggy code to handle this case. I did not know how to evaluate it. It came not to my mind, that its just an illegal move and one only has to generate the nextbest one. Stefan Mertin told me the difference several times, but it did not help, only the advice of Peter Woitke, just delete this stupid code, was the right instruction level. I'd be interested in hearing how people handle graph history interaction issues. A move from a specific board position may be legal or illegal depending on how that position was obtained. I use the simple ko position as part of the hash key, and generally ignore positional superko and situational superko when doing my search. That seems to make sense since the superko situations are pretty rare while ko is fairly common. I've considered putting in some simplistic superko avoidance such as tracking a bit more history of captures in the hash key, but I haven't convinced myself that it's worth it yet. I think I have three hash values for every position - black stone, white stone, and simple ko. I don't need to disallow ko by color since it only ever applies to one color at a time (the color to move). ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Who else uses Hashtables in UCT?
On Tue, 2007-07-10 at 16:14 +0200, chrilly wrote: I have no finished a plain vanilla 9x9 Suzie-UCT Version. The UCT-tree is stored in a Hashtable. I am interested who else uses this approach. The reason for using a hashtable was: I was too lazy to implement an explicit tree. At least at 9x9 I have no problem with memory size. In fact there are 2 hashtables, one for the Alpha-Beta and one for the UCT-Version. With the default parameters each version uses 160 MB. A chessprogrammer in Go-Land, part X: I interpreted SuperKo as repetition of position (which seems to be correct, although Stefan Mertin told me, there are numerous versions of SuperKo). I used the Nimzo/Hydra code to detect this. But there is a - not a very subtle - difference between Go and Chess. A move which generates a repetition of position is in Chess legal, in Go it is'nt. But I assumed its legal and had quite complicated and buggy code to handle this case. I did not know how to evaluate it. It came not to my mind, that its just an illegal move and one only has to generate the nextbest one. Stefan Mertin told me the difference several times, but it did not help, only the advice of Peter Woitke, just delete this stupid code, was the right instruction level. Most programs use positional superko which means that it's illegal to repeat a position although this doesn't apply to pass - it's always legal to pass even if though it repeats the previous position. Note that it doesn't matter who's turn to move it is in positional superko. If a move would repeat a board configuration (even if it's a different side to move) it's considered illegal. There are other ko rules which discriminate and depending on who you ask some are more correct than others. The difference from chess is that it's just plain illegal to repeat in GO. In chess it's legal, but a draw if the opponent claims it. Most chess programs code it up as an instant draw. - Don Chrilly ___ 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] Who else uses Hashtables in UCT?
On 7/10/07, chrilly [EMAIL PROTECTED] wrote: I have no finished a plain vanilla 9x9 Suzie-UCT Version. The UCT-tree is stored in a Hashtable. I am interested who else uses this approach. Steenvreter has a hashtable. The reason for using a hashtable was: I was too lazy to implement an explicit tree. At least at 9x9 I have no problem with memory size. In fact there are 2 hashtables, one for the Alpha-Beta and one for the UCT-Version. With the default parameters each version uses 160 MB. A chessprogrammer in Go-Land, part X: I interpreted SuperKo as repetition of position (which seems to be correct, although Stefan Mertin told me, there are numerous versions of SuperKo). I used the Nimzo/Hydra code to detect this. But there is a - not a very subtle - difference between Go and Chess. A move which generates a repetition of position is in Chess legal, in Go it is'nt. That actually depends on the rules; there is no world-wide consensus on how to deal with long cycles. Traditional rules allow some long cycles, unpolished western rules declare any repetition illegal. But I assumed its legal and had quite complicated and buggy code to handle this case. I did not know how to evaluate it. It came not to my mind, that its just an illegal move and one only has to generate the nextbest one. Stefan Mertin told me the difference several times, but it did not help, only the advice of Peter Woitke, just delete this stupid code, was the right instruction level. :-) Steenvreter recognizes the following 3 types of long cycles (all situational): (1) winning cycles (the player that completes the cycle gains in each round because he captures more stones or equivalently passes more), (2) losing cycles (opposite of winning cycles), and (3) balanced cycles (both sides capture the same number of stones). In the tree, when a long cycle is detected the corresponding result (win/loss/jigo) is directly used instead of the normal MC-playout result. Losing cycle results are only used locally (they are not propagated down to the root because any other move should be considered better than a direct loss); for updating the other nodes the search simply continues on another move. Erik ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UCT caveat (was in Explanation to MoGo paper wanted)
On 7/10/07, Jacques Basaldúa [EMAIL PROTECTED] wrote: When you favor defense (or attack) you may think: This is unbiased since some times it favors black and other times it favors white But the fact is when black is in danger at the root of the tree, it is in danger in most of the tree, therefore the trick gets the evaluation wrong. Well, this is subtle enough that I don't understand it. What are two positions that it would compare incorrectly? - Brian ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Explanation to MoGo paper wanted.
Nonetheless, a program that could not only play a decent game of go, but somehow emulate the _style_ of a given professional would be of interest, would it not? Is this the case in chess? If so, I've never heard of it. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Explanation to MoGo paper wanted.
On 7/10/07, Chris Fant [EMAIL PROTECTED] wrote:
Nonetheless, a program that could not only play a decent game of go, but
somehow emulate the _style_ of a given professional would be of interest,
would it not?
Is this the case in chess? If so, I've never heard of it.
I don't think that it is (but I don't know much about computer chess).
For a machine to learn the _style_ of anything whatsoever, by my reckoning,
is a rather difficult task.
As an example, I was once privileged to attend a talk by Donald Knuth in which
he described a somewhat difficult task that he was working on, and challenged
us to think about, namely, to teach a machine to recognize the _style_ of some
arbitrary font.
Far more difficult than mere OCR (optical character recognition), wherein one
already possesses the entire set of alphanumeric characters and symbols of a
particular font, this task was something like the following:
Given only an uppercase 'B', the numeral '4', and a lowercase 'a':
Reproduce the entire font.
As you might well imagine, doing that could prove a bit trickier than OCR.
It's almost akin to reading the mind of a calligrapher: What strokes would be
used to create a '7', an 'f', or an ampersand (''), given that we know only
the three characters above? At what point do we think we have the right answer
to such questions? If we think that we are finished, and then compare the font
that font we have created against the actual font, then have we failed if it
turns out that there are differences? That is, to what degree must our created
font match _exactly_ the actual font? Pixel for pixel? Or is there a degree
of leeway, within which we may be satisfied that we have succeeded?
In a similar way, being able to recognize the _style_ of some particular pro
go player is a bit trickier than merely creating a program that plays.
It's a different problem altogether.
Just as Knuth's problem is harder than OCR, so too is capturing a pro's style
a greater challenge than creating a go program.
[Disclaimer: I've forgotten the exact details of Knuth's challenge. He had
determined that there were three or four characters that had the necessary
and sufficient details (loops, serifs, horizontals, verticals, diagonals, etc.)
to permit recreating the entire font, for most fonts anyway. I don't remember
which characters, nor how many, although I'm sure it was either three or four.]
--
Rich
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Go programming as a profession.
Was looking up engines when I came across the Go++ website. Is it still the #1 engine in the world? Most of the titles on the page seem to refer to the late 90's and early 2000's. Anyway, the one thing that shocked me the most was Over 400,000 copies sold in Japan! At $39.95 that's just shy of $16 million. Wow Even at $1 a copy that's almost 1/2 a million dollars. Is this normal? ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Go programming as a profession.
At $39.95 that's just shy of $16 million. Wow Even at $1 a copy that's almost 1/2 a million dollars. I'm reminded of a post this list about 10 years ago (maybe by Mark Boon?), probably in the context of winning the Ing prize: if you are a very good programmer, there are easier ways to get rich than writing a go program. Darren ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] Go programming as a profession.
The list price in Japan is closer to $100 than $39. This is my Japanese product (AI Igo version 15): http://www.ifour.co.jp/product/aiigo15/ and you can see it lists for 13,440 yen (about $110). The other strong programs have similar prices. His royalty is more than $1 per copy. Since Go4++ hasn't participated in a competition recently, it's probably not #1. KCC Igo is the best, based on Gifu results. David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joshua Shriver Sent: Tuesday, July 10, 2007 8:53 PM To: computer-go Subject: [computer-go] Go programming as a profession. Was looking up engines when I came across the Go++ website. Is it still the #1 engine in the world? Most of the titles on the page seem to refer to the late 90's and early 2000's. Anyway, the one thing that shocked me the most was Over 400,000 copies sold in Japan! At $39.95 that's just shy of $16 million. Wow Even at $1 a copy that's almost 1/2 a million dollars. Is this normal? ___ 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/
