Author: Robert Hyatt
Date: 11:47:51 09/06/01
Go up one level in this thread
On September 06, 2001 at 13:58:00, Uri Blass wrote: >On September 06, 2001 at 13:17:52, Robert Hyatt wrote: > >>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. > >Do you assume that all programs use the same extensions? No. I am counting pure plies, not search depth. If a program can do a 1-ply search, and search forward (using extensions) for a total of 26 plies, then white captures the pawn on ply 27 (the first ply of the q-search). The only requirement is that the search has to see all the way to that capture on move (ply) 27 to see that the win of a pawn can be forced. Whether they do that with a 1 ply + extension search, or a 26 ply + captures search doesn't really matter. > >I can imagine that programs with more extensions can see it in less plies even >with perfect move ordering. > >Uri Yes, but we are not talking the same "plies" here. I am talking about the number of moves in the variation that proves a pawn can be won. You are talking about the reported iterative search depth. Which is a different thing altogether.
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.