On Wed, Nov 14, 2007 at 10:40:15AM -0500, Álvaro Begué wrote: > Anyway, go programmers should probably not be using a whole lot of dynamic > memory allocation, and certainly not enough to make the performance of > free() matter at all.
Doesn't that depend strongly on how a program works? For example, if you had a program which were really good at the endgame --- or, perhaps, just a program which deeply understood sente and gote as used in the middlegame, so that it could correctly cope with things like a play becoming double sente as the game progresses --- it'd be natural for it to manipulate expressions at least as complicated as combinatorial games, because we know that combinatorial games arise in the limit of exactly known position values. And good luck working with combinatorial games without heap allocation. If that seems implausible to you, very well, but the UCT approach didn't strike me as particularly plausible when I heard of it, either, and I find myself forced to remain openminded about what's going to turn out to be important in strong programs. -- William Harold Newman <[EMAIL PROTECTED]> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C "'C'est la vie,' said the old folks, 'just goes to show you never can tell.'" -- Chuck Berry _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
