Don Dailey wrote: > I would like to ask you to reconsider your feeling on this, because I > think > they are misguided. Let me explain why I feel that way and you can take > it > for what it's worth.
amen > Many months ago there was a discussion on computer chess and people were > divided on the issue if most of amazing progress in computer chess was due > to software or hardware. Most had always assumed it was hardware and that > is the standard sound bite cut and pasted into articles that talk about > the > progress of computer chess. However, I was swayed convincingly to the > software side of the issue and I think most real experts on computer chess > agree now that it's roughly even - the software progress in computer chess > has been absolutely astounding when measure over decades and it has kept > pace and perhaps even outstripped hardware. amen > But here is the thing ... the whole process was long and gradual and it > never involved any major breakthroughs. Yes, there were things that > stood > out and some refer to them as breakthroughs, but none of them were even > a > fraction of what we got from Monte Carlo methods for Go. Go was really > ripe for this one because it was long overdue anyway and global search was > the only way forward and had been dismissed for so long. amen > At each step along the way, it was almost impossible to imagine making a > program play much stronger as it seemed like we were doing everything > reasonably possible. amen > In 2004 a program called "Fruit" came out and it astounded the computer > chess community with it's incredible strength. The strange thing about > this is that there are NOW chess programs that are hundreds of ELO > stronger > than Fruit, running on the SAME hardware. It's not hardware, it's real > software advancements, good ideas and good engineering. And there have > been no "major breakthoughs" since Fruit to produce these programs. Even > Fruit itself did not have any new ideas of major significance, it just did > a > lot of things a little bit better. (Probably the biggest factor in Fruit > was something called LMR which was worth something like 50 ELO, but even > that was just an old idea all polished up with a better formulation. > And > many think the major thing that made it strong was simplicity and bug free > code.) amen > The lesson from this, is that if you are standing in a dense forest, you > can only see a few trees around you. YOUR feeling that we have "almost > reached our limit" and that we have exhausted all the good ideas in MCTS > and > need something new is certainly shortsighted and I mean no disrespect. I > have fallen for this kind of thinking a few times myself. amen > What you are very likely going to see is gradual steady progress and > constant refinements of ideas and incremental improvements which will add > up > to an overwhelming amount of power in a relatively short time. There > will > not be any major new ideas but probably a lot of little ideas, each > contributing a small amount. amen > Here is an example of how this works, using a principle every top chess > program author understands very well: amen > Imagine that you can make your program strong enough in a months time to > win > 51% of the games against the previous version. If you can do that, you > will have added something like 5-10 ELO to the strength of your program. > 5-10 ELO is a small amount of improvement and it is so difficult to > measure > that it requires thousands of games to verify. So we are not talking > about a herculean task. And yet, if you do that for a year you will > have added 1 dan of strength to your go program! 1 Dan in 1 year is a > lot. amen > But I don't think the engineers in Go programming think like that yet. > (Maybe some do, I applaud you if you so.) They seem to get frustrated > if > they cannot find an immediate big gain and speak of not making progress > without some major breakthrough because they cannot imagine their program > playing much better without one. The way you make a strong program is > 1-10 ELO at a time over months and years. I think it is extremely > unlike > that anybody will find a single 1 dan idea that is relatively painless to > code up. However there are probably many good ideas that will add up to > 1 dan with a lot of engineering and tuning and hard work. amen > I admit that a big hurdle with GO is the ability to test 10,000 games (for > instance) in a reasonable amount of time. It would probably tax the > patience of most GO authors to try to measure small improvements and thus > the mentality to only look for big things and dream of major > breakthroughs. > But I seriously doubt anything that is quickly measured is likely to be > found and I'm convinced that even the best ideas need a lot of refinements > and engineering - the stuff that takes so long and requires so many games. amen > So my predictions is that without anything really major (but no doubt some > new small ideas) we are going to see your KGS 5 and 6 dan and much higher > in > 5 to 10 years. I'm assuming that the good engineers in computer go will > improve on their testing methodology (and I think multi-core newer > hardware will make this much easier to do.) amen --------------- AMEN ! Many small amens give one big AMEN. Ingo. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de _______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
