Don Dailey wrote: > Dave Dyer wrote: > >>>> A standard alpha-beta driven search takes exponentially more time >>>> with search depth, so an exponential increase in speed results in >>>> a very small incremental improvement in "seeing'. Improvements >>>> in the quality of the evaluation at anything less than exponential >>>> cost more effective at improving playing strength. >>>> >>>> >>>> >>> What do you expect to see? A non-exponential technique that leads to >>> arbitrary playing strength? >>> >>> >> My point is only that time spent trying to make alpha-beta as fast >> as possible is basically time wasted. It doesn't matter if that time >> is spent assembling faster hardware, coding in languages with better >> runtime performance, or just plain hand coding to "optimize". Faster >> alpha-beta will never be a significant contributor to improved playing >> strength. >> >> I forgot to mention that UCT and alpha beta seem to have about the same behavior - about 100 ELO per doubling in GO at 19x19.
Also there are reasonable alpha/beta GO programs such as AYA. It's not even clear to me what the best search method is. Right now it seems to be some version of Monte Carlo with best first search. But a lot of things are being tried and I think some people are trying alpha/beta and getting good results. Of course alpha/beta doesn't imply "brute force." An alpha beta search can be quite selective. It doesn't have to end with a stupid evaluation function either - it can try to be smart. - Don > I think you are like the drunken sailor, no disrespect intended. It > appears that a doubling is worth about 100 ELO points in 19x19 GO. > That means a speedup of even 1.4 is worth 50 ELO points. 50 ELO means > you will beat me about 57% of the time. If you are drunken sailor, you > probably don't care that much - hardware will catch up in just a few > months. So you might as well take this shortcut and avoid C. You > also might as well not optimize - it makes your code ugly. It's > probably only worth another 50 ELO points anyway. If your mentality > is that you are only interested in the "big wins", you are not > respecting the little things that over time add up to big wins. It > means you probably don't care about making your program slightly smarter > either. You are going down the wrong path. Eventually, you become > bankrupt and have a crummy program and don't know why. > > Of course I came from computer chess. I spend a month optimizing a > very old chess program I wrote with my partner. I found some kind of > speedup every day for a good while (I don't remember the time period > exactly, but it was perhaps a month or so.) Most of them were very > modest - and to make ourselves respect the process we didn't veiw them > as speedups, but instead converted them to ELO rating points > gained. We knew that 5 ELO is hard to measure in terms of actual > results, but getting 5 ELO a few days in row turned our program from a > modest program to a champion program. This program won a > championship. > > There are a bunch of other issues too like bugs. It's important to have > few bugs. They kill your program too. That is one argument in favor > of using a high level language, but it's a dear price to pay. > > - Don > > > > >> Choosing C because it executes faster is silly. Choosing C because >> you can start with GNUGo might be perfectly sensible. >> >> _______________________________________________ >> 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/
