Author: Robert Hyatt
Date: 14:44:46 10/04/01
Go up one level in this thread
On October 04, 2001 at 13:06:28, Uri Blass wrote: >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 The scientist in me will not let that stand unchallenged, however. For every case where a parallel search happens to find a better move quicker, there is an equal case where the parallel search searches a branch that is not needed. They offset each other. you can not depend on random chance to always roll a "7" for you and let you win a fortune at the crap table. You will actually lose more than you win, if you play long enough. That is the nature of the game and the randomness it depends on.
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.