Re: [computer-go] MC - Estimating a moves true probability of winning
Hello, Just an explanation on something I may have explained badly. I see we agree in the fundamental. Correcting bias in that estimate should lead to better sampling. This is usually called continuity correction http://en.wikipedia.org/wiki/Continuity_correction. The estimator is not really biased, but because it is a quotient of integers it requires a continuity correction specially when the integers are small or zero is involved. That is included in the intervals I suggested. To use these results, you must make some assumption about the underlying distribution of a move's probability of winning. That's the good news. You don't. There is no need to understand what complex mechanism produces p. Only that: same position == same p. If you take a good look at your tests, they will make very specific null hypothesis which in effect make at least some assumption about the underlying distributions (or try to wash away all effects with the central limit theorem). Well, the assumption that p is estimated from the binomial because we are counting Bernoulli experiments of constant p is a mathematically sound method used universally. It does not require go knowledge, that's what i meant. When n is big enough, the binomial converges to the normal and that's what we use for inference. Jacques. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Big board. Temperature
In CGT the temperature is the difference between the value if you play and the value if you pass. The name question should be answered by a native English speaker, but I guess it is an common use of the word hot. Let's call it hotness ;-) Jacques. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MC - Estimating a moves true probability of winning
Well, the assumption that p is estimated from the binomial because we are counting Bernoulli experiments of constant p is a mathematically sound method used universally. It does not require go knowledge, that's what i meant. When n is big enough, the binomial converges to the normal and that's what we use for inference. another nice feature of knowing that you're dealing with the binomial is that you can deal with your *actual* distribution in a much more efficient way than if you instead pretend that you're sampling from a distribution that you will eventually converge to. which is slow, and ugly, by way of comparison. :) s. Be a PS3 game guru. Get your game face on with the latest PS3 news and previews at Yahoo! Games. http://videogames.yahoo.com/platform?platform=120121 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Big board. Temperature
Le vendredi 2 mars 2007 12:55, Jacques Basaldúa a écrit : In CGT the temperature is the difference between the value if you play and the value if you pass. Thanks for your lights :) Ok i better understand my confusion. In Go CGT-temperature applied to yose strongly looks like ordinary points (moku). I just found http://senseis.xmp.net/?TemperatureCGT The conclusion is much more clear for me: The temperature of a game is also a measure of the average gain a player can make by a gote play in it. It has the same value as the miai-value of the play, in go terms. Alain. The name question should be answered by a native English speaker, but I guess it is an common use of the word hot. Let's call it hotness ;-) Jacques. ___ 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] GTPv3
On 3/2/07, Markus Enzenberger [EMAIL PROTECTED] wrote: On Thu March 1 2007 05:22, Łukasz Lew wrote: The most important thing is controller - engine architecture. There are situations that engine would like to have the control. For these requests come up once in a while, but IMO the clear separation between who is the controller and the engine is a big advantage of GTP. It makes both the implementation of engines and controllers much easier. I agree Can you do simple, single-threaded controller scripts with UCI? Is it used for as many use cases as GTP is, ranging from regression testing to any kind of automated experiments with Go engines? The Go server protocols are designed for humans and asynchronous sending of messages between them at any time, but does it make sense for a computer engine to allow it to start chatting, whenever it feels like it? I think it is sometimes important to allow the engine to sent some information including chatting. I think that GTP should not be extended in a way that makes the implementation of engines or controllers more complicated. I agree. So is there any solution not using stderr? In gogui this is solved by using stderr to send those commands, but: - stderr is not network transparent Remi Coulom convinced me that it is more convenient for the engine to write to standard error and he was right. Typically the GTP interface is only one of several interfaces to lower level Go engine code and you don't want to make lower level code aware of this. I would like to have GTP flexible enough to be the only interface needed. One idea I had in mind to address this was to allow the engine to send comment lines before the actual response. Then you could tunnel the standard error output through a network connection in these comment lines, maybe starting with a special keyword. That is interesting. But why before the actual response? It should be allowed to sent it any time, and it's a matter of server implementation when It will parse it. It would need only a minor modification to existing controllers to ignore all text before the response. Alternatively, one could extend the tools GtpServer and NetGtp in the GoGui package to internally transmit standard error text in such a way, that would be transparent for the engine and controller on different hosts. 6. Position setup. I had conversation with Marcus about setup in GoGui. And we concluded that there should be a separate command for that. The coming version 1.0 of GoGui will support a setup command. It is a simplified version of a suggestion I made a while ago to the GTP list and uses a syntax like: gogui-setup b A1 b B2 w C3 Originally I had an undoable setup command in mind to incrementally follow setup stones in SGF trees, but it is much easier for engine programmers to handle only full position setup on empty boards, so GoGui will follow the SGF properties incrementally and translate setup nodes into clear_board / gogui-setup sequences. - Markus ___ 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] GTPv3
On Fri, 2007-03-02 at 17:31 +0100, Łukasz Lew wrote: I also have a strong feelings about variables. I believe there should be standard GTP command, var seems to be a good name, that would write list of variables (with types?) var var_x would print value of var_x var var_x value would set the value. What do You think? It's a bad idea for a protocol like this in my opinon. What purpose does it serve to give variables unless you also have a protocol to agree on what the variables mean?If I send var x = 7 what is the controller supposed to do with that? With UCI there is a provision for a program to communicate to the controller all the settable options. These do not have to be pre-defined options although many are common. Your program may have a special setting unique to it alone and you can tell the interface about it, and the end use of the program can change that parameter or option via the interface. It's really quite nice and simple. This is the closest thing I can think of to what you are talking about.There are several classes of options and you can provide ranges. The options can be boolean such as turning something on and off, values with ranges, etc. UCI is significantly more advanced compared to GTP but I'm really hesitant to change a standard, even if it's not perfect. To go forward, GTP has to be completely changed and I have mixed feelings about this. - Don Łukasz On 3/2/07, Markus Enzenberger [EMAIL PROTECTED] wrote: On Thursday 01 March 2007, Phil G wrote: I would like to suggest using the command setup_sequence instead to miror the play_sequence command which was introduced by GoGui (I believe). I finally followed the GTP (draft) standard and used a prefix separated by a hyphen for non-standard extension commands, so play_sequence became gogui-play_sequence. setup_sequence wouldn't be a good name, because the setup stones are not a sequence, you can specify them in any order. There will also be a second command gogui-setup_player for setting the color to play, but support for that is optional, since it is not strictly necessary that the engine is informed about the color to play. The genmove and play commands are sent with a color argument anyway. If an engine does not support gogui-setup, setup stones will be sent as moves as previously. - Markus ___ 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/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
On Fri, 2007-03-02 at 13:45 -0500, Don Dailey wrote: The contoller would send commands such as continue_search which must return in a fraction of second, possibly with a move.This would be truly awkward but possible. Of course, a good GO program doesn't have to STOP searching just because it's responding to a continue_search command. It could anticipate that it will soon be getting another continue_search command. But you see things start getting much more complicated, what if it doesn't get another continue_search command? You lose the simplicty of GTP where you get a command, respond to it, wait for the next command etc. With UCI this is trivial from the engines perspective. The program simply responds to commands, pretty much the same as GTP but it's also allowed to send informational messages along the way. It's actually really simple to implement. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] KGS bot curiosity
I don't suppose this matters, but it seems odd. A day or two ago, I launched GnuGo3pt7 to play in the British Room. It played happily there. Then today, I saw it was not in the British Room (though it can't have been long gone, there was a finished game of its there). Instead, it was in a room called Academy of Flood and Fire, playing a game there against aaronaaron. After a while, aaronaaron escaped, and it reappeared in the British Room. Nick -- Nick Wedd[EMAIL PROTECTED] ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] KGS bot curiosity
We are also not understanding what we are seeing with SlugGo in the Computer Room. It is playing games (we don't know where) and we cannot seem to get a game with it. Cheers, David On 2, Mar 2007, at 11:11 AM, Nick Wedd wrote: I don't suppose this matters, but it seems odd. A day or two ago, I launched GnuGo3pt7 to play in the British Room. It played happily there. Then today, I saw it was not in the British Room (though it can't have been long gone, there was a finished game of its there). Instead, it was in a room called Academy of Flood and Fire, playing a game there against aaronaaron. After a while, aaronaaron escaped, and it reappeared in the British Room. Nick -- Nick Wedd[EMAIL PROTECTED] ___ 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] GTPv3
Łukasz, Yes, I would like to see some of these problems solved. As I mentioned, UCI doesn't have any of these issues. After thinking about this, there is perhaps a backwards compatible solution: 1. Don't change GTP, just add to it. 2. Have a command called asyncronous which tells the engine that it supports the new asyncronous protocol. (Or maybe the response to the protocol_version command is enough) 3. If the engine suports this, then it can accept commands like stop_search and it can send certain informational commands. If the controller is asyncronous, the engine could still SEND informational commands even if it was not capable of ACCEPTING commands out of order. You could get all the benefits of UCI without breaking backward compatibility. One issue is that the engine canont assume the more advanced GTP protocol, it must remain in backward compatible mode (should not send informational messages) unless that is directed by the controller. One way around this is to define a different set of commands that are designed to be asyncronous. Then the engine can feel free to accept or reject them. For example instead of using genmove, the new protocol could send begin_search, which is understood to be an asymetric command. If your program gets a begin_search command it is allowed to send informational messages while searching.Those informational messages must be specified by the protocol and contain information such as nodes searched, score, current best move, search depth, etc. But the program doesn't have to send information it doesn't want to. If your program doesn't do a search it is not required to send a search depth, etc. If your engine accepts and responds to begin_search it is understood that it will accept and respond to stop_search - Don On Thu, 2007-03-01 at 13:22 +0100, Łukasz Lew wrote: Hi, There are some issues that are not so well defined in GTP v2. Maybe GTP v3 should be released to avoid too much legacy later? 1. The most important thing is controller - engine architecture. There are situations that engine would like to have the control. For instance When he want to send commands to GUI to draw something while he is working. In gogui this is solved by using stderr to send those commands, but: - stderr is not network transparent - syntax is not standardized - there is no confirmation about success / failure for those commands. 2. The second thing is that there are many variables in the engine (komi, board size, time, etc). Developers tend to have more of them to control various parameters of the engine. End users could like to have some control over strength of the algorithm, etc. 3. If GTP would supports chats, KGS would probably implement it. 4. Opponent identification. 5. Interrupt. Users do not always want to wait until the program finish work. GoGui uses comment #interrupt to do it, but this is a hack. (this is somewhat related to 1.) 6. Position setup. I had conversation with Marcus about setup in GoGui. And we concluded that there should be a separate command for that. Would You like to have those issues solved? I hope we can get somewhere. :) Best Regards, Łukasz ___ 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] KGS bot curiosity
On 3/2/07, Nick Wedd [EMAIL PROTECTED] wrote: I don't suppose this matters, but it seems odd. A day or two ago, I launched GnuGo3pt7 to play in the British Room. It played happily there. Then today, I saw it was not in the British Room (though it can't have been long gone, there was a finished game of its there). Instead, it was in a room called Academy of Flood and Fire, playing a game there against aaronaaron. After a while, aaronaaron escaped, and it reappeared in the British Room. Nothing strange. The human player can interrupt the game (provided he isn't a chronic escaper, in which case he would lose by forfeit immediately) and resume it later by loading the unfinished game in whatever room he wants. nando ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
On 2-mrt-07, at 16:34, Don Dailey wrote: Łukasz, Yes, I would like to see some of these problems solved. As I mentioned, UCI doesn't have any of these issues. After thinking about this, there is perhaps a backwards compatible solution: 1. Don't change GTP, just add to it. 2. Have a command called asyncronous which tells the engine that it supports the new asyncronous protocol. (Or maybe the response to the protocol_version command is enough) 3. If the engine suports this, then it can accept commands like stop_search and it can send certain informational commands. I think this may be a viable solution. Better in my opinion than defining asynchronous commands. Of course the current division betweem controller and engine make things easy. But it also inhibits some more sophisiticated behaviour. If the two parts can communicate what they do and don't support I think it's should be possible to allow for two-way communication. Whoever doesn't want to go through the trouble can still only support the simpe master-slave setup that it currently is. Mark ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
