Re: [Computer-go] gtp question - can black make 2 moves in a row.
On Sa, 2015-09-05 at 23:51 -0700, Ray Tayek wrote: > i am guessing that the client should make the moves if he gets them. > > does anyone know for sure? From the GTP specification, page 18, 6.3.3 Core Play Commands: "play: [...] Consecutive moves of the same color are not considered illegal from the protocol point of view." Hellwig ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] gtp question for topological go program
Hi Ray, GTP is a strictly asymmetric protocol, not intended to be used directly between players. The specification draft http://www.lysator.liu.se/~gunnar/gtp/gtp2-spec-draft2/gtp2-spec.html expresses this clearly (1.3 Communication Model): The protocol is asymmetric and involves two parties, which we call controller and engine. The controller is typically some kind of arbiter or relay and the engine is typically a go playing program. All communication is initiated by the controller in form of commands, to which the engine responds. So if you want to let two instances of Go players play each other, you need some controller in between, possibly split in two halves, one half on either side of a network connection, with a separate protocol for communication between the two controllers. This is the usual situation when two programs are playing on a (remote) Go server. Hellwig ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [computer-go] matching 2 engines with sanity checks
On Mon, 2009-08-03 at 10:39 +0200, Folkert van Heusden wrote: CGOS does sanity checks on the moves played by the engines that are matched. Problem is that it might take a few hours before bugs get triggered (due to scheduling of matches). GoGui can let an engine play against itself and then does also does sanity-checks but it is possible that certain bugs in an engine won't get triggered. So I was wondering: are there any other tools available for matching engines WITH validity-checks? Perhaps twogtp and an instance of GNU Go is what you are looking for. Hellwig ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] gtp which version to implement?
On Wed, 2009-07-15 at 11:24 +0200, Urban Hafner wrote: Carter Cheng wrote: Thanks everyone for the help thus far. I have been looking at the GTP protocol page and I am curious which version of the protocol I should try to implement if I want to communicate with the servers. Should I be looking at the GTP 2.0 draft version? You should implement (part of) the draft. It's widely used nowadays. I'm not sure if there's any server out there that uses the old version. Just to be clear on this point: GTP is not a server protocol, but a protocol between a controller and an engine. If you want the engine to connect to a server, there is still a bridge needed, which communicates with the engine through GTP and with the server through whatever protocol the server is speaking. Hellwig ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Experimentation
On Tue, 2009-07-07 at 17:09 +0100, Christian Nentwich wrote: [..] Unless you can, in the end, show that your algorithm can outperform another one with the same time limit, you have not proved that it is an advance. That is why tournaments are played with time limits, not limits on the number of playouts. Time is an important dimension of the game of Go. This is somewhat funny: normally, it is Don who argues along these lines.. ;-) Hellwig ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Language
On Wed, 2007-11-14 at 07:25 -0800, steve uurtamo wrote: And it's not fast either. Free() has a reputation of being slow, and that's not surprising if you look at the way it is almost always implemented: scanning a list of addresses in order to amalgamate the newly freed memory with adjacent free areas. this is a burden for the OS, not a defect in the language. as far as the executing code is concerned, it's just releasing responsibility for the block attached to the pointer. the OS can merrily insertion sort it for all i care, but that's being handled elsewhere and isn't a function of the language. heck, the kernel could tell me that it's done within 2 microseconds and then give me an error on my next malloc because it isn't really done putting it back into place. but that's fine with me, because of the way that i use memory. i don't mind having to make friends with the OS. it follows pretty clearly-defined rules. No, sorry, this has nothing to do with the OS, but only with the implementation within the stdlib library. The kernel gets involved only when malloc() has exhausted its free list and is requesting another big block of memory via the brk() system call, which happens infrequently. So it *is* a function of (the implementation of) the language. having garbage collection happen at random times would really, really make it difficult for me to profile. the reality is that the way i use memory, i know when i need it and when i need to get rid of it, and very frequently, once i've gotten all that i need, i don't need to ask for more for a really long time and can point to the exact place where i'm going to ditch it. That's my point: Not all uses of memory follow the pattern you are describing. My personal experience is: if you can tolerate the 5-10% loss in execution speed, a real garbage collector is invaluable. it sounds like you're working on more sophisticated code than i am, from the way that you describe using garbage collection. i'm just a speed junkie who needs to use all of my ram to do scientific computing and i don't mind counting all of my own beans. The type of software I had in mind was an interactive system, running for days (or even months) without restarting, together with the possibility of creating function closures. I find it hard to imagine how you can do that without a garbage collector. I realized such a system in plain C, but I wrote my own garbage collector for it - I just saw no other way to determine when objects created by the user's processes could be freed. Hellwig ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Language
On Wed, 2007-11-14 at 12:30 -0800, Christoph Birk wrote: I write (astronomical) instrument control software in C that runs for days (upto weeks). I call malloc() when I need memory and free() when the particular sub-task is done ... no problem. Then you are a lucky guy... ;-) With closures you almost never know when exactly the task is done. They can float indefinitely within your system, they can get part of other data structures, and last but not least, they are cyclical in nature. *I* would have had many problems without garbage collection. But I will happily concede that these particular problems may play no roll at all in computer Go - except if you decide to program in a functional language. Then again, you won't do that without a good GC. Hellwig ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Language
On Mon, 2007-11-12 at 20:17 -0800, steve uurtamo wrote: C garbage collection: free(). Well, that's not garbage collection. You will begin to notice that if you are using shared data structures with different lifetimes. The question that comes up again and again is can I free this structure here or does any part of my program hold a private pointer to this piece of data? It is sometimes possible to group freeing objects (e.g., a compiler can free data structures it needs to compile a function when the end of the function is reached - this is called arena freeing) but not always. very fast. And it's not fast either. Free() has a reputation of being slow, and that's not surprising if you look at the way it is almost always implemented: scanning a list of addresses in order to amalgamate the newly freed memory with adjacent free areas. My personal experience is: if you can tolerate the 5-10% loss in execution speed, a real garbage collector is invaluable. Hellwig ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GoGui and python
Thomas, On Fri, 2007-08-24 at 17:26 -0500, Thomas Nelson wrote: command = raw_input() print = myName\n the following is taken directly from the protocol specification: - 2.6 Response Structure If successful, the engine returns a response of the form =[id] result Here '=' indicates success, id is the identity number given in the command, and result is a piece of text ending with two consecutive newlines. - Please note the two consecutive newlines. As others have already pointed out, you have to flush the output if it is buffered. Hellwig ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GoGui and python
On Fri, 2007-08-24 at 19:11 -0400, George Dahl wrote: He has two consecutive newlines since print adds one unless the print statement has a comma at the end. - George Ah, thanks, didn't know that. I suspected this to be the error because the two newlines in responses are in my experience the most overlooked detail in the GTP spec. Hellwig ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Java hounds salivate over this:
On Fri, 2007-06-15 at 15:12 -0700, steve uurtamo wrote: my last $0.02 on this -- let me know when you've written a kernel in java, and tell me how fast your operating system (written entirely in java) runs. what? that can't be done? :) Well, in fact that can be done... :-) http://www.jnode.org/ Hellwig ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] CGOS GTP
On Wed, 2007-03-28 at 13:44 -0700, Christoph Birk wrote: On Wed, 28 Mar 2007, Don Dailey wrote: One of the features I want to put into CGOS involves a new gtp command to inform the program of the opponent, game number, etc.I have not decided on the format of this new gtp command and it will of course not be required that you implement it.I will have to read the standard to see if there is already something in place. Any suggestions?Basically I want to CGOS does no speak GTP. It uses your own protocol that already sends this information. Well, I think CGOS in this case means the CGOS client, which indeed does speak GTP. But you are right, this need not be specified by Don - but if he doesn't, everybody will invent his own way to get this information to the engine. Hellwig ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Help me test CGOS
On Wed, 2007-03-28 at 17:49 -0400, Don Dailey wrote: That's awesome if you have a cgos client in C, I would be happy to post the source code and/or binaries. Yes, this is a cgos client in C, but only for the old protocol yet. You can download the source from http://homepages.fh-giessen.de/~hg53/go/cgosGtp.tar.gz Please feel free to do with it whatever you want. I warn you however, the protocol may change - I have not finalized it. Although it's not likely anything major. That's the reason I wanted to wait a little bit until I start to translate the new client to C. Hellwig ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Help me test CGOS
Jacques, On Tue, 2007-03-27 at 11:03 +0100, Jacques Basaldúa wrote: Could the source code of this client be open? I just finished the translation of the old TCL script cgosGtp.tcl to plain C (for those of us who don't want to run a scripting language interpreter just to connect to CGOS). You can find it here: http://homepages.fh-giessen.de/~hg53/go/cgosGtp.tar.gz Please note that this is not quite what you are looking for, but I intend to do the same translation with the new script as soon as it has stabilized. Don, I translated your script almost without changes. I changed the log output to use the arrows a bit more consistently, though. And the program waits for an answer to the quit command sent to the engine; this is according to the GTP specification which requests The controller must receive the response before the connection is closed on its side. Hellwig ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
