Author: Robert Hyatt
Date: 21:56:12 07/31/02
Go up one level in this thread
On July 30, 2002 at 21:30:25, Uri Blass wrote: >On July 30, 2002 at 19:39:40, Robert Hyatt wrote: > >>On July 30, 2002 at 07:57:17, Uri Blass wrote: >> >>>On July 30, 2002 at 07:28:42, Uri Blass wrote: >>> >>>>On July 29, 2002 at 17:39:53, Uri Blass wrote: >>>> >>>><snipped> >>>>>I am going to write it in valid C but first I need to understand what I need to >>>>>store in the hash tables when the depth is 0 and when to store moves that lead >>>>>to exact scores and how to do it. >>>>> >>>>>Uri >>>> >>>>I think that I know the problem that caused >>>>my program to be slower after adding exact scores. >>>> >>>>The remaining depth when I call qsearch can >>>>be smaller than 0 because of null move pruning >>>>(it was no problem in regular search because >>>>in that case I call qsearch when the remaining depth >>>>is 0 but it was a problem when I tried to probe >>>>the hash tables with the remaining depth. >>>> >>>>I think that I will change the line >>>>val=-alphabeta(depth-4,-beta,-beta+1); >>>>to the line >>>>if (depth>=4) >>>>val=-alphabeta(depth-4,-beta,-beta+1); >>>>else >>>>val=-quies(...) >>> >>>When I think about it again I may extend by >>>more than one ply so even if (depth>=4) >>>may be not exactly the same as without it(in the position that >>>I tested it was the same but I think that there may >>>be cases when it is not the same). >>> >>>I wonder if it may be a good idea to change the order in my >>>alphabeta and first calculate extensions and >>>only later call alphabeta. >>> >>>In that case I can record a more exact depth in the >>>hash tables. >>> >>>Today the exact depth may be dependent >>>on the previous moves and not only on the position >>>(in most cases previous moves do not change but >>>in case that they are captures or pawn >>>to the 7th they may change) >>> >>>Today the varaible depth that I record in the >>>hash tables does not give the full information about >>>the depth because there is another varaible >>>for partial extensions. >>> >>>I do not know if it is a good idea to store the >>>partial extensions because in that case it means that >>>I have less space in the hash tables. >>> >>>Uri >> >> >>simple and correct solution. In your q-search, assuming you are going to >>store/probe hash entries there, just store with depth=0, period. That will >>eliminate the problem you have above. There is no need for any sort of >>"depth" value in quiesce() anyway, so get rid of it and call HashStore() >>(or whatever you call your function) with a constant of zero (0) in the >>depth parameter... > >No problem but the problem is what depth to record in the hash tables before >returning alpha or beta. Why not the current depth remaining? Any other value will be wrong. > >The first problem is that it is possible that alphabeta(depth-1,alpha,beta) is >practically a result of search to depth-1 and not of search to depth if the >position or the last move triggered an extension. > >I think that this should be no problem because the only important thing is that >the depth that I store in the hash tables is deeper when the real depth is >bigger. > >Another problem is that I have a variable of partial extensions. >Alphabeta with the same parameters can give different result if my partial >extensions are different(I remember the sum of partial extension for every ply >in an array and if the sum is too big I reduce it and increase the depth by 1). > >It was no problem in using hash tables only for order of moves but it may be a >problem if I try to use hash tables to prune the tree so I guess that I need to >use only one varaible for depth before doing it or to compromise in pruning the >tree and to prune only when the depth that is stored is one ply bigger than the >depth that I am going to search. > >Uri Fractional extensions don't cause any problems. The only rule you have to follow is that you must be consistent in how you apply extensions. If you apply them on the basis of the alpha or beta values, then you are guaranteeing instabilities.
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.