Computers + random = can of worms. What if I get a fast benchmark by implementing the fastest, most awful, random number generator imaginable? What if every one of my "random" playouts looks the disturbingly similar?
As to the relevance, the time-eaters in my heavy playouts are different from the time-eaters in my light playouts. - Dave Hillis -----Original Message----- From: Don Dailey <[EMAIL PROTECTED]> To: computer-go <computer-go@computer-go.org> Sent: Thu, 9 Oct 2008 2:44 pm Subject: Re: [computer-go] programming languages On Thu, 2008-10-09 at 14:17 -0400, [EMAIL PROTECTED] wrote: > >>> The http://shootout.alioth.debian.org/ site, ... > >>> > >>> If we, as a community, could come up with a sufficiently detailed > >>> description of light playouts algorithm (see the current "Light > >>> simulation : Characteristic values" thread), there is no reason > that > >>> this algorithm couldn't join them. > > > Many potential ways to speed up light playouts involve taking some > liberties regarding the uniform distribution of moves. Specifying and > verifying the rules here, looks messy to me. > > Also, light playouts are more of an intermediate step than an end goal > for engines. Is making them faster all that relevent anymore? I think you're missing the point. This would be nothing more than just a benchmark. You would be free to implemented it any way you like as long as it conforms to the general guidelines, so all programs should be equivalent. However one program might use a totally different board representation than another. Specifying the rules is probably not too hard but verifying them would be trickier. The simplest way to verify is: 1. benchmarks that provide strong empirical evidence. 2. Source code is available for all to inspect. I agree that this is far from the best way to implement a program but it would really be useful as a benchmark for board games. I would trust the results of this shootout way beyond the computer language shootout. This is because it's an actual program that should also be able to play a real game. John Tromp did something along the same lines with connect-4. He had a java and C implementation that were equivalent in output. I actually didn't trust his benchmark because he wrote C code generic and simple, not like a high performance guru would write C code. I can't really be too critical unless I actually were to try to improve on the C version. To me the advantage of C is that you can write code that you wouldn't write in Java. There is very littl e advantage of C over Java otherwise. If you start with the best Java program you can and then port it to C as faithfully as possible, you get a different result than if you take the best possible C program you can write and try to port it to Java. For each language, you would probably write fast code differently. I think the right way to do John's benchmark is to get each language zealot in competition with each other. Let the C programmer prove he can do it much faster. And the Java programmer can respond if he wants to. - Don > > - Dave Hillis > > > > ______________________________________________________________________ > McCain or Obama? Stay updated on coverage of the Presidential race > while you browse - Download Now! > _______________________________________________ > 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/
