I don't understand why people always make a big issue out of this. I'm sure that Chris Fant realizes we "lack infinite resources" but it's important to understand the scalability properties of such things.
So when Chris Fant said, "given infinite resources" it's not crazy talk. It's essential to understand this. If you carefully read the Mogo paper you will notice that they also make a big deal out of the theoretical properties of the UCT algorithm. They say it's guaranteed to converge on optimal play (or something like that.) I have not heard anyone criticize them for making such a "silly" statement. Don't they realize that Mogo don't have the hardware resources to play optimally? Why didn't you attack them for that? But in fact it's more than just a theoretical property that has no real meaning in practical terms. It DOES have a practical meaning. It's not so important whether optimal play is reachable in the near future, what is important is that if it isn't scalable, it's self limiting. Let's look at this another way: If you don't handle PSK in the UCT part of the tree, your program is guaranteed NOT to converge on optimal play. You may believe this is not important, but it is. At 5 kyu, doing superko only at the root may seem more than enough and you might not really notice much of a strength decrease. However, when the program advances to 2, 3 or 4 dan and more - perhaps with other refinements and additional hardware then this little glitch will start to stand out like a sore thumb. It's not so much the fact that the bug prevents it from achieving perfect play but it already hurts it a little, and it's guaranteed to hurt it more and more as it gets stronger and stronger. Any non-scalable feature a program has is worse than a "governor" in an automobile engine. In an auto engine a governor kicks in to prevent the vehicle from going beyond a certain speed but it doesn't hurt the speed before that. But a non-scalable feature in a program is more like adding a wind sail to your vehicle. It hurts at any speed, but it hurts more and more as you go faster and faster (unless you are going slower than the wind and in the same direction :) Sometimes there are practical considerations, but when there are none, you should always do the right thing. Lazarus has two move "make" routines. One of them computes a Zobrist hash incrementally and the other doesn't. A key is stored in the stack. No stack is built during fast play-outs, but during UCT search I stack positions and their keys. If you really want to be careful, compare complete positions if the hash key matches. Otherwise, your program is not scalable! :-) (No, I'm not quite that paranoid.) - Don On Fri, 2007-05-18 at 17:38 -0700, steve uurtamo wrote: > > > But then you have an engine which does not converge to perfect play > > > given infinite resources. > > > > I assume that you're joking, given: a) a current lack of infinite resources, > > and b) a current lack of "convergence" of any kind. > > > > No, but I can rephrase for those spooked by the concept of infinity: > > > > "But then you have an engine that stops scaling at an unknown point." > > my thinking is that in a situation like this, hardware advances aren't > yet the main limiting factor. and since the strength of 19x19 programs > of any variety are still many hundreds of ELO away from strong play, big > algorithmic changes (and not how those algorithms scale in the > distant hardware future) are still what really matters. > > s. > > > > > > > ____________________________________________________________________________________ > Moody friends. Drama queens. Your life? Nope! - their life, your story. Play > Sims Stories at Yahoo! Games. > http://sims.yahoo.com/ > _______________________________________________ > computer-go mailing list > [email protected] > http://www.computer-go.org/mailman/listinfo/computer-go/ _______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
