Author: KarinsDad
Date: 07:22:25 04/15/00
Go up one level in this thread
On April 15, 2000 at 02:50:06, blass uri wrote:
>On April 15, 2000 at 01:29:18, KarinsDad wrote:
>
>>On April 15, 2000 at 00:08:41, blass uri wrote:
>>
>>>On April 14, 2000 at 14:41:08, KarinsDad wrote:
>>>
>>>>On April 13, 2000 at 20:32:01, Robert Hyatt wrote:
>>>>
>>>>[snip]
>>>>>
>>>>>You are talking about "forward pruning" which is full of danger. Your
>>>>>eval likely doesn't understand deep tactics, yet you will be letting it
>>>>>dictate which moves you search looking for tactics and which you don't.
>>>>>
>>>>>It is _very_ difficult to do this and not cause huge search problems...
>>>>
>>>>
>>>>That is why Fathom will be so dangerous ("yeah, right" says all of the old
>>>>programmers). It does a type of forward pruning. Whether it will be successful
>>>>with this, only time will tell.
>>>
>>>I understand that you mean to selective search(this is what the old programmers
>>>did) that and not to searching part of the moves to a reduced depth.
>>>
>>>
>>>I think that the first thing to do in order to check these pruning ideas is to
>>>take a database of about 10,000 comp-comp games(you can use the ssdf games) and
>>>see if your pruning idea rejects the moves that were played.
>>>
>>>If you reject good moves that were played even only in one case out of 1000
>>>positions then your forward pruning try is not good.
>>>
>>>If you only reject some bad moves that were played because of bugs then your
>>>pruning idea may be good(probability not more than 1/1000000 for an error)
>>>
>>>Uri
>>
>>I agree that this is a place to start, but I think your numbers are way too
>>restrictive. Many positions have 2 to 4 great moves, not just 1. So, if my
>>program comes up with the comp chosen move 40% of the time or higher, I will be
>>feeling pretty good.
>
>Maybe I did not explain myself well.
>
>The main problem is the error of prunning of good moves because it can cause
>tactical mistakes and not the error of not prunning bad moves.
>
>I do not expect your program to prune all moves except 2 to 4 great moves.
>
>If you can prune only 20% of the moves because you are sure that they are bad
>when the probability to be wrong in prunning is less than 1 to 1000000 then your
>idea may be good.
>
>If you prune good moves in 1 out of 1000 cases then you can lose by tactical
>errors so I think the pruning idea is not good and the fact that you get bigger
>depthes does not compensate for the tactical errors that may happen in more than
>1 out of 1000 cases because a mistake of prunning not in the root may lead to a
>wrong move.
>
>Uri
Now I understand what you are saying. And yes, that is kind of the idea.
However, there are some other things to consider. If I prune out a good move low
down in the graph, that may not matter. The reason is that I may come back later
and search down it's descendents anyway. It is all a matter of time and using
your time to good effect.
For example, what good is it to search down 20 ply on one line? Chances are that
you are not searching the best nodes somewhere along that line anyway. So, you
pick a reasonable depth to search, you search what you consider to be the best
moves down to that depth, you extend if you find something interesting, and once
you are done doing this for each of the possible moves at ply 1, you go back and
search nodes that were second best earlier on. And then if time permits, third
best, etc.
If your selective search REALLY understands chess, then this is not much
different than how a human would do it. The difference is that the program would
search a lot deeper than a human in most cases and it would search a lot more
nodes. The REAL difficulty is in getting the program to REALLY understand chess.
And I think the only way to do that is to break chess down into a series of
concepts, each of which adds to the overall understanding of the game.
For example, say that you put a SEE into your evaluation in order to prune out
really lousy captures. That will not help unless it is sophisticated enough to
understand that when pxN, the pawn was pinned against the rook, so Bxr and all
else being equal, pxN is lousy due to losing the exchange. Now, normally, this
has to be detected within the search. But if your evaluation function could
detect it without taking up too much time, then you could prune out captures
that look good, but are really bad without using your search engine. How much
does that save? Who knows? But it seems reasonable to think that the more
sophisticated the evaluation, the better the search should be. A sophisticated
evaluation would understand a positional sacrifice and would extend the search
there. And, it could distinguish between a positional sacrifice and a plain old
loss of the exchange. But it isn't easy by a long shot.
KarinsDad :)
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.