Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Teaching computers to think

Author: Bob Durrett

Date: 05:59:25 03/15/04

Go up one level in this thread


On March 15, 2004 at 08:47:38, Andrew Wagner wrote:

>	I got to thinking last night. This is a very bad idea for people like me who
>are not experienced at it. Folks, don't try this at home. So... what was I
>thinking about? Thinking. Bear with me here folks, this is kind of a long post.
>
>
>	Computers and humans really think in quite opposite approaches. In classic
>alphabeta, we start by generating all legal moves and throwing out the bad ones
>until (hopefully) we have the one good one left. But of course no human thinks
>like this. They start with NO moves, and use positional, tactical, and pattern
>considerations to generate just a few possible good moves. Then for each of
>those moves, they again generate just a few responses (rather than every legal
>response as alphabeta would), and so on.
>
>	Now, in one sense humans search much more efficiently than computers. Because
>they don't look at ridiculous captures like queen takes pawn which is defended
>by another pawn, they are saved a lot of time and effort. The flipside of this
>is that computers are ABLE to look at millions of these ridiculous captures in
>the time it takes a human to look at just a few moves.
>
>	However, if you think about it, human searching can hardly be called efficient
>most of the time. I mean really, for those of you who play, how often to you
>calmly, coldly calculate your way through a tree like described above? We tend
>to skip steps, jump around in our thinking, get distracted, and so on.
>
>	So, the question becomes...What if a computer could codifiy that thinking
>process, using existing techniques like pruning, extensions, hash tables, and so
>on, to change the shape of the tree **based on positional considerations**. Let
>me illustrate with a position here.
>[d]r1b1q1k/pQp/2p1p3/p1PpP3/P2N1P1B/2P1R3/6PP/3n2K1 w - -

[D]r1b1q1k/pQp/2p1p3/p1PpP3/P2N1P1B/2P1R3/6PP/3n2K1 w - -

>
>White has sacrificed a rook to reach this position, and now unleashes a surprise
>queen sacrifice for mate in 6. Qxg7+ Kxg7 Bf6+ Kg6 Bg7+ Kh5 Rg5+ Kh4 Nf3#.
>
>	So for any engine which has check extensions, this tactic should be easy,
>right? But, how many times will check extensions prove to be a waste of time? I
>mean, if the king is well-defended, it's silly to search a line where you
>sacrifice all your pieces to break open the king, only to discover that you have
>nothing left to mate him with.
>
>	But in this position, it's easy to see that check extensions are called for.
>Look at black's pieces. 4 of the 5 are on the first rank. Look at the center.
>It's completely closed, making fast movement of pieces to defend the king
>impossible, and white has more space. Look at white's pieces. They all point
>menacingly towards the black king. If you're well-trained to look for it, it
>should be easy to realize that some kind of sacrifice to drag the king into the
>open should be considered.
>
>	Many advances have been made in chess programming. We have some amazingly
>sophisticated techniques and shortcuts. But we're still brute-forcing our way
>through. Can't we instead start looking at the human thought process involved in
>chess, and define it in terms of these different techniques? This way, rather
>than simply trying every technique on a position and hoping one of them works
>and offsets all the time wasted on inadequate techniques and silly lines, we
>would have a toolkit to use, and can pick a tool based on the position, just
>like humans do.
>
>	Here are three ideas I had about how to "nail down" the way humans think:
>
>	1.) Show positions to a strong player, and have him say/write/type the first
>thing that comes to his mind. This "inkblot" sort of approach, repeated many
>times over, would give us some kind of indication as to what really the key
>factors are in a position.
>
>	2.) During the course of a series of games, have a strong player (or two strong
>players, playing each other) write down the first thing that comes to mind when
>a move is made by his opponent. This could give us tremendous insight into move
>ordering techniques.
>
>        3.) Take some classic books like Fine's Endgame book, or Vukovich's "Art
>of Attack" and translate them into terms of search techniques like extensions
>and pruning.
>
>
>	Now some may be thinking that these ideas would seem to be representative of
>the classic brute-force approach. But what I'm really suggesting is not only
>move-ordering, but move-list generation, based on positional considerations. Of
>course, some brute-force will still be required, just to make sure everything is
>tactically sound. But it seems to me that we are doing things backwards to use
>brute force, and prune from there, instead of to "un-prune" some moves first,
>and brute-force to see if we can beat that.
>
>	One final thing: I realize that I'm a young, naive, beginner chess-programmer,
>and suggesting these things is the equivalent of a 2-year-old questioning
>newtonian physics. So please, don't bother informing me of this, I already know
>it. I also realize that some or most of these ideas have probably been suggested
>before. But if nothing else, I hope this leads to an interesting discussion on
>why we do things the way we do. Thanks for reading, and I look forward to your
>responses.



This page took 0 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.