Re: [computer-go] creating a random position
George Dahl wrote: How would one go about creating a random board position with a uniform distribution over all legal positions? Is this even possible? I am not quite sure what I mean by uniform. If one flipped a three sided coin to determine if each vertex was white,black or empty, then one would have to deal with stones with no liberties somehow. Could those just removed? As I remember from theory of probability, you can create such a uniformly random position this way[1]: 1. create a really random position, i.e. traverse all intersection and assign a black/white/empty state at random to each; 2. if it happens to be not legal, discard and repeat step 1. I believe it should be very fast, and this mustn't be difficult to check. I.e. rate of discards should be low enough for speed of algorithm to be speed of step 1 times C, where C is small. However, this will tend to give you very artificial-looking positions. Whether it is fine for your use-case, you know better. [1] http://en.wikipedia.org/wiki/Rejection_sampling Paul ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
Don Dailey wrote: On Thu, 2007-03-08 at 12:27 -0500, Weston Markham wrote: There is no race condition because commands _are_ read synchronously. But responses _may be_ sent asynchronously. Paul I'm not sure that I understand Paul's explanation, so I'll try out my own: Any race condition that occurs here is entirely the fault of the engine. The engine is already responsible for serializing all of the responses that it makes. Any failure to do so would allow interleaved responses, which could not possibly be understood by the controller. So, at the time that the async_genmove is permitted to write its asynchronous response, (it may have to acquire a lock in order for this to be the case) it is unambiguous whether or not the response to abort_async_genmove has been sent. I think I am confused. So what you might get is this: 1. controller sends async_genmove 2. controller (after some period of time) sends abort. 3. engine responds to aysnc_genmove 4. engine responds to the abort search In my example, I'm assuming the engine send it's response to asyn_genmove at the same instant the controller wanted to abort the search, so the engine didn't see the abort comming before it was too late. Isn't this a race condition? I believe this should cause no problems because the controller can simply ignore the non-relevant response to genmove (it knows it send abort.) But I don't think that is what you are talking about. [Please CC to GTP list] Engine should send response in this way: acquire response lock check if asynchronous command hasn't been aborted/completed if not, send response release lock In other words, there is potential for race condition, as with anything asynchronous. But properly implemented engine doesn't have a race condition situation. Yes, it is more complicated. That's why I'm against making asynchronous stuff required, only optional. Paul ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [gtp] Re: [computer-go] GTPv3
Gunnar Farneback wrote: Example 3: Like example 2, but abort command comes too late. Controller: 1 async_genmove black 2 abort_async_genmove 3 play black C3 Engine: =1 !1 E5 =2 =3 Maybe it should then read ?2 not in progress It also makes sense to forbid an async_genmove (or simple genmove for that matter) until the previous genmove/async_genmove has finished. The engine should just fail with a predefined error string; I think it is really cumbersome for the engine to try synchronization here and serves little purpose. Paul ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
Don Dailey wrote: On Wed, 2007-03-07 at 22:53 +0100, Gunnar Farneback wrote: * To abort the asynchronous genmove, the controller should send the (synchronous) command abort_async_genmove. If the engine has not returned the asynchronous genmove response before responding to the abort command, it is no longer allowed to return a move. I'm open for discussion on the exact name and whether it should return an error if the move had already been sent (I don't think it should). But what about race conditions here? The engine may be responding to the async_genmove command an instant before it realizes an abort command just arrived. In this case it would be violating your rule but it wouldn't be anyone's fault. There is no race condition because commands _are_ read synchronously. But responses _may be_ sent asynchronously. Paul ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
I have not been following this discussion closely, but let me throw few ideas in. First about a new protocol --- I'm strongly against. I remember it was a real pain to force GTP over backward GMP. Now you want to force some (probably better but more likely more complicated) protocol over GTP which works and has many uses. I'd say you'll spend several years on this and yet it might not succeed. And it will most likely only hurt computer go community, not bring an advantage. About asynchronous move generation. I'd propose something like this. Add some form for asynchronous responses. E.g. '=[id] ...' means success, '?[id] ...' means error (this is as now) and '%[id] ...' means asynchronous response. Maybe for asynchronous commands it makes sense to make id mandatory. Responses must not be mixed, i.e. you cannot start a synchronous response inside asynchronous or vice versa (else they will be impossible to parse properly.) So, for old or not sophisticated engine it could look like this: 1 genmove white 2 best_so_far 3 abort_thinking =1 F14 ?2 unknown command ?3 unknown command But for engine with support for asynchronous responses: 1 genmove white 2 best_so_far 3 abort_thinking %2 D17 =3 ?1 aborted Clients can easily distinguish between two scenarios. To make it even easier, one can add one command: supports_async_protocol (optional command) -- returns 0 or 1, if not implemented, 0 is assumed by controllers and they may opt to never send commands meant to be replied asynchronously. Paul ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Why not forums?
Dmitry Kamenetsky wrote: Why can't we use proper forums instead of this outdated list? No, please don't. Last time I checked, forums were unusable. I find it much easier to just delete messages I'm not interested in than to check forums periodically. (And yes, I'm subscribed to some 10 lists, also most [and by far] messages just get deleted instantly.) Paul ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
