Author: Robert Hyatt
Date: 11:57:23 08/26/02
Go up one level in this thread
On August 26, 2002 at 12:52:40, Steffen Basting wrote: >Hello! >Some days ago, I posted about the bad branching factor in my chess program. >Here's the output of the starting position as an example: > >time depth nodes value principal variation >=============================================================================== >0 1 29 10 g1f3 >0 2 127 -6 b1c3 b8c6 >0 3 380 18 b1c3 b8c6 g1f3 >0 4 2141 0 b1c3 g8f6 g1f3 b8c6 >0 5 9174 16 b1c3 b8c6 g1f3 g8f6 e2e4 >1 6 54535 8 b1c3 d7d5 g1f3 b8c6 e2e4 g8f6 >7 7 408066 21 b1c3 d7d5 g1f3 d5d4 c3b5 b8c6 e2e4 >53 8 3220020 18 b1c3 c7c5 e2e4 b8c6 g1f3 e7e5 f1b5 g8e7 > >3220020 nodes, 53 seconds: 59630 nodes/sec >q-nodes: 2944182 evals: 2944182 >value: 18 >my move: b1c3 >principal variation: b1c3 c7c5 e2e4 b8c6 g1f3 e7e5 f1b5 g8e7 > > >Here's another output of the following position: >1r3rk1/1q4p1/6P1/8/6P1/8/PPP3P1/1K1QR2R w - - 0 1 > >time depth nodes value principal variation >=============================================================================== >0 1 285 441 h1h7 >0 2 609 441 h1h7 b7b2 >0 3 5207 454 d1d4 b7g2 h1h7 >0 4 12194 479 d1d4 >0 4 31061 536 d1d4 b7c6 d4e4 c6e4 >4 5 241205 511 d1d4 >7 5 450249 451 d1d4 f8f4 d4e5 f4g4 e5e6 >12 6 750245 476 d1d4 >22 6 1329714 514 d1d4 f8f4 d4e5 f4f6 h1h7 f6g6 >130 7 7392912 489 d1d4 >7392912 nodes, 130 seconds: 56434 nodes/sec >q-nodes: 7045522 evals: 7045522 >value: 489 >my move: d1d4 >principal variation: d1d4 >Well, this is a mate in 5. As i do not use check extensions (yet) i am not >surprised that it doesn't find the mate in less than 10 ply. But what I do not >understand is: why does the branching factor grow from about 2 to 7? > > >In this position - (which is from the first game against a human ;-)), however, >it does fine: >2krr3/2pb2pp/1p1p1p2/p2P4/P1P2PP1/1P2R2P/3B4/2KR4 w - - 0 1 > >time depth nodes value principal variation >=============================================================================== >0 1 234 44 e3c3 >1 2 620 46 e3e8 d7e8 >1 3 2221 47 e3e8 d8e8 d1g1 >1 4 6526 40 e3e8 d7e8 d1e1 c7c5 >2 5 44643 45 d1e1 e8e3 e1e3 d8e8 f4f5 >3 6 138710 51 d1e1 e8e3 e1e3 d8e8 e3e8 d7e8 >7 7 446883 47 d1e1 e8e3 e1e3 d8e8 e3e8 d7e8 d2e3 >20 8 1449252 36 d1e1 e8e3 e1e3 d8e8 e3e8 d7e8 f4f5 c7c5 > >1449252 nodes, 20 seconds: 69012 nodes/sec >q-nodes: 1367941 evals: 1367941 >value: 36 >my move: d1e1 >principal variation: d1e1 e8e3 e1e3 d8e8 e3e8 d7e8 f4f5 c7c5 > >If you have a look at the q-nodes and evals, they're always the same. Is this >normal behaviour if you call eval from the quiescence search? Does it mean that >all higher plies are always extended with qsearch? Why are there so few "normal" >positions searched, but so many q-nodes?! Captures are near the tips. There are more positions there than there are at the root of the tree...] As far as your qnodes/eval counter, think about it for a minute. Where do you call evaluate() from? The top of quiesce()? :) So for every call to quiesce() there is an immediate call to evaluate(). The counters _should_ match. :) >And is this strange branching factor due to a bad move ordering? >Sorry if the positions i posted above don't show the problem. Perhaps you could >make some suggestions which positions to use... What kind of ordering are you doing. I noticed you said "no hashing" which hurts. What about null-move? Without that your branching factor will be pretty fat in most positions... > >Thanks for your comments! >Kind regards, Steffen > >PS: (as reply to Dann Corbit) I don't use hashtables (yet) :-)
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.