Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: New crap statement ? Perpetuum mobile(test positions for Deep Fritz)

Author: Uri Blass

Date: 10:06:28 10/04/01

Go up one level in this thread


On October 04, 2001 at 12:21:07, Sune Fischer wrote:

>On October 04, 2001 at 10:19:33, Uri Blass wrote:
>
>>>Move ordering has that bit of randomness about it, sometimes you pridict wrong
>>>and you get the right move second (or even last).
>>>Most of the time you would get the right move first though (or else just reverse
>>>move ordering, so that is a safe assumtion).
>>>Example:
>>>
>>>1. move has 60% chance of being the best.
>>>2. move has 30% chance of being the best.
>>>3. and rest 10%
>>>
>>>Search move 1 => succes has 60% chance.
>>>Search half move 1 and half move 2 in the same time => 0.5*(60+30)=45% chance.
>>>
>>>It will not pay off on average, only once and a while.
>>
>>It is not so simple.
>>programs do not have exact scores for a lot of moves and they search for good
>>enough moves and not for the best moves.
>
>Are we talking about the alpha-beta algorithm here?
>The better the move ordering you have, the more cut-offs you get and the faster
>you go, so you want the best moves to be searched first.

This is exactly the point I want the best move to be searched first.

If move A is leading to a forced checkmate and move B is leading to win a pawn
then one processor may always start from winning a pawn and decide that winning
a pawn is good enough when 2 processors may find the mate,remember the mate, and
always start from the mate in every iteration.


>You can reverse the whole move ordering, it will end up finding the same move
>(or some with equal score) but it will be alot slower, worst case would be
>minimax speed.
>I don't know what the parallel version of A-B() does either, but I figured it
>was something along those lines.
>
>>if 2 processors search for a good enough move then it is possible that they can
>>find in small part of the cases better good enough move than one processor and
>>later in the next iterations the computer can remember that better good enough
>>move to get a better branching factor.
>>
>>Uri
>
>Yes, "in small part of the cases" agreed, but not on average.
>
>-S.

These small part of the cases may be important to get better branching factor
because the program is going to reject losing moves for the fact that there is a
mate in 1 and not for losing a pawn.

Uri



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.