On Sat, 2008-05-10 at 07:01 -0700, Carter Cheng wrote: > Thanks everyone for the responses. My go skills are somewhat limited (only > 6-7kyu on KGS) so hopefully I am not belaboring the obvious. > > I have a few followup questions- > > 1) What mathematically is a seki? I know this is a local draw but can it be > determined statically at some point in all cases using some sort definition > without placing stones on the board (i.e. searching). I only know of three > cases here- the 1 eye each case with one shared liberty. two shared liberties > and the half eye situation.
Hunter's book "counting liberties and winning capture races is probably a good reference. With no eyes, two shared liberties, and no outside liberties is seki. If both have one (one point) eye, one shared liberty and no outside liberty is seki. That should cover 99% of the cases that happen in games. I was already thinking I should go back and review that book... > > 2) I am guessing hash maps get quite large if they are exhaustive. i.e. > (nxn)^3 can quickly become quite big. Or do they tend to be sparsely > populated? Actually, it's 3^(nxn) which is much larger. As with any hash, the idea is to make the hash small enough that hash collisions are sufficiently rare that there's still good speed. This will change with how many patterns you have and the quality of your hash function for those patterns. > > 3) GTP and time management and scoring after two passes. Are these issues > discussed anywhere? Do libraries like Orego and Libgo contain code that > already does this which can be used as a reference? I'm sure just about every bot has code to do that stuff. One common time management strategy is to do (time_left-buffer)*10%. I probably went overboard with my time management code [1]. While my (lack of) handling of final_status_list made the highlight reel recently, I do have code that's work quite well before I switched to an MC bot. The code can be found in gtp::final_status_list at [2]. Note that it marks all non-benson-alive stones as dead instead of all stones provable as dead by benson's algorithm as dead. Of course, this handling was based off of when my bot would pass. There's probably smarter logic out there... What will work best for you probably depends on what logic your bot contains. For example, I doubt gnu go's dead stone marking logic will have much value for your new bot. [1] http://housebot.svn.sourceforge.net/viewvc/housebot/trunk/housebot/timecontrol.d?view=markup [2] http://housebot.svn.sourceforge.net/viewvc/housebot/branches/0.4/housebot/src/gtp.cpp?view=markup _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
