On Sat, 2008-10-11 at 21:46 +0200, Denis fidaali wrote: > > On point 13. > 1 stone captures, may eventually be "hard" for some implementation. > I think using game length as a criterion gives more freedom.
I definitely considered that. My own program returns the number of stones captured (and a list of those stones if I ask for it) and so it's easy for me, but wonder if there are programs where this would be difficult to detect? My arguments in favor of the rule is that it's not quite as artificial as setting some arbitrary limit and I think this would not unduly delay the terminations of games. With a limit of hundreds of moves, some games would go hundreds of moves beyond what is necessary. Are there any MC programs out that cannot detect whether they made a one stone capture and it would be unduly difficult to fix this? > > Then you have to specify what to do with those pathological games anyway. > Do you score them "as they are", or do you drop them. I do count them. You score them as is. You may not get the "correct" score, but after all these ARE random games and we expect this to be extremely rare. > The rule for counting is probably quite standard too. I give a point for > each stone present. Then for each empty stone, i give a point to the side > who has all orthogonal control of it, if any. Yes. Tromp/Taylor which are Chinese rules. > > I usually implements super-ko checking very late, if i do at all. > > I often start by selecting either the first or the last "best" move, > rather than picking one at random. Although picking at random > makes me more comfortable somehow. It could be interesting > to see how much difference it makes. Of course everyone is free to implement any variation they want, controlled by switches and such. The idea is to have an extremely reliable benchmark and this will also be very helpful for new developers as this also would serve as a good "first program" for new developers and they could have confidence that they got all the details right. > > Finally, about the size. Is it supposed to be 9x9 only ? It can be anything you want, but I suggest that you develop a program capable of playing on any board size. Having said that, you can get a little more speed if you code to just 1 specific board size. Lazarus compiles to any ODD board size but it's fixed at compile time and I have to recompile to get other board sizes. I doubt this optimization is worth very much and it's annoying that I have to fetch a different binary in order to play other board sizes. Also, I don't really keep up with how new processor families change the rules. I know that I USED to get a nice speedup several years ago by using as many constants as possible (as opposed to variables) but I have no idea whether (or how much) this is true today. > 9x9 only gives more freedom to fine tune for this size. > It may make the implementations less useful, if someone > knows another sizes the light-policy could succeed on. > (like maybe studying 7x7 and such ?) How do you define "succeed?" It works on all board sizes, it just works better on smaller boards. You could equally say it doesn't work on any board size since there are ways to build stronger programs. - Don > _________________________________________________________________ > Email envoyé avec Windows Live Hotmail. Dites adieux aux spam et virus, > passez à Hotmail ! C'est gratuit ! > http://www.windowslive.fr/hotmail/default.asp_______________________________________________ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/
signature.asc
Description: This is a digitally signed message part
_______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
