Author: Uri Blass
Date: 15:36:57 04/08/04
Go up one level in this thread
On April 08, 2004 at 17:34:50, Ed Schröder wrote: >On April 08, 2004 at 13:36:03, Uri Blass wrote: > >>On April 08, 2004 at 12:22:15, Ed Schröder wrote: >> >>>On April 08, 2004 at 09:04:15, Harald Lüßen wrote: >>> >>>>On April 08, 2004 at 07:10:29, Daniel Shawul wrote: >>>> >>>>>Hi >>>>>Here are some questions >>>>> >>>>>2.In Ed's paper there are some tricks done at horizon. >>>>> trick one if(score - (margin + largest hanging piece) > beta) >>>>> don't do quiescence >>>>> trick two if(score - 900 > beta) >>>>> don't do quiescence >>>>> My question is every body does >>>>> score=eval() >>>>> if(score > beta) >>>>> don't do quiescence; >>>>> So i don't see how the tricks work? >>> >>> >>>>His alpha is our beta and vice versa. >>> >>>Really? >>> >>>If true I need to re-read some papers :) >>> >>>To clarify, suppose an aspiration search with a 0.50 window and a best move with >>>a 0.20 score then going to the next iteration I get a window of: >>> >>>ALPHA = -0.30 >>>BETA = 0.70 >>> >>>Your comment suggests: >>> >>>ALPHA = 0.70 >>>BETA = -0.30 >>> >>>Ed > > >>No >> >> >>suppose that we start with position of big advantage for white and you have >>alpha=3.00 beta=4.00 >> >>His point is that the meaning of alpha and beta is different. >>Search is a recursive function so alpha=3.00 beta=4.00 turns out to be >>alpha=--4.00 beta=-3.00 after a recursive call. >> >>You try to prune moves before calling search so you may use >>alpha=3.00 beta=4.00 when most programmer try to prune moves after calling >>search so they have alpha=-4.00 beta=-3.00 > >Confusion all over here, I call "search" only once. I understand that unlike most programmers you do not have a recursive function for search and I guess that what you do is better. > > >>Your pruning trick when it is white to move is > >Realize the above definition is ambiguous, crucial: do do you mean before or >after "make_move"? I assumed something wrong about your search so I think that what I meant is not important now. I think that it is better not to try to understand what I guessed about your code but to get better explanation of your code. It is possible to understand ideas even without understanding what you do exactly in your search but it is better to get some clear code like Tord suggested. > > > > >>if(score - (margin + largest hanging piece) > 4.00 pawns) >> don't do quiescence >> >>It is translated after calling search to >> >>if (score+margin+largest hanging piece<-4.00 pawns >>don't do qsearch. >> >>I guess also that your score is not from the same side to move like other >>programmers. > >That could be very well the case, for me ALPHA means the "best_score_so_far" and >BETA is the upper limit of the window. As far as I know this is the case also for other people. I assume the internal organization of my >search is different than other programs although the outcome and behavior is the >same. I guess this is correct. In a nutshell: > >static int ab[64]; // create depth based stack for alpha-beta >static int depth; > >When I am on ply-3 in the search: I guess you mean the third ply and not ply minus 3 but I am not sure. > > depth=3; > ab[depth] = ALPHA > ab[depth-1] = BETA If I understand correctly depth is not the remaining depth like in my program but the distance in plies from the root position but it is possible that I understand wrong. > >When going one ply deeper in the search (ply-4), I do: If I understand correctly one ply deeper in the search means one ply forward in the game. > > depth++; > ab[depth]=ab[depth-2]; > >Then Alpha-Beta pruning: > > if (ab[depth-1] + score < 0) // no alpha/beta -> do next move > ..... prune here ...... > >Are you still with me? > >Ed :) I am not used to that code so I will need to think about it but I guess it is equivalent to normal alphabeta and it is better to use it because you have some array of alpha and beta when I have only one alpha and one beta at every moment so you have the option to use more information. 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.