[Computer-go] 7.0 Komi and weird deep search result

"Ingo Althöfer" 3-Hirn-Verlag at gmx.de
Wed Apr 6 06:55:51 PDT 2011


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



More information about the Computer-go mailing list