Author: Uri Blass
Date: 10:58:00 09/06/01
Go up one level in this thread
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? I can imagine that programs with more extensions can see it in less plies even with perfect move ordering. Uri
This page took 0.01 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.