Author: Robert Hyatt
Date: 10:17:52 09/06/01
Go up one level in this thread
On September 06, 2001 at 12:02:52, Peter Fendrich wrote: >On September 06, 2001 at 10:21:40, Robert Hyatt wrote: > >>On September 06, 2001 at 06:12:16, Odd Gunnar Malin wrote: >> >>>> >>>I was pondering with this strange results from Tiger and Wilhelm and (and my >>>engine :) ). >>> >>>There is other possibilities for long search time (many nodes) before the score >>>change. If you don't save hash when depth=0, eg. after returning from qsearch >>>you get such results ( I don't save hash in qsearch). >>> >>>From my engine: (score change from 140 to 226) >>>hash save when depth=0 -> 430k nodes >>>no hashing when depth=0 -> 8731k nodes >>> >>>Odd Gunnar Malin >> >> >>I don't hash in the q-search either. However, fine70 runs better with poor >>move ordering, due to hash grafting. If you search the best move first at >>every node, this takes 26 plies to solve, IIRC. If your move ordering is >>less than optimal, you require fewer plies to find the correct move (Kb1). >> >>At ply 26, you should see winning another pawn, for a score of +2 plus whatever >>positional edge you assign for creating a passed pawn. In a few more plies >>the score should jump yet again... and again... > >At ply 25, mine (Terra) jumps up to +3,4. Does that mean less optimal move >ordering? How do you know? >Couldn't it be at some point better move ordering? >//Peter No. I know it because the solution is 26 plies, minimum. The only way to solve this with fewer than 26 plies is through hash grafting. Works like this: You first search the right move at ply 1, but you search a poor move at ply 2, and reach a position where you can force the win of a pawn. Then you search the right move at ply 2, but discover that you can force the game to a position you encountered in the first search, where you forced a win after weak defense. You use this hash information to prove that a position is won, even though you really can't search deeply enough to see the win. If you search best-first every time, this can't possibly happen, and it will take 26 plies. It has been a known issue for years, and is why programs solve this anywhere between 16 plies and 26. And it is why, if you change the hash size, you will likely change the depth you solve it. In fact, it is pretty common to increase the hash size and increase the depth required to find the Kb1 move, because hash moves improve move ordering... A real pain, of course. :)
This page took 0.02 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.