Author: Vincent Diepeveen
Date: 11:51:10 11/28/00
Go up one level in this thread
On November 28, 2000 at 12:52:57, Scott Gasch wrote: output diep single cpu after 1.e4,e5 2.d4,d5: 150 mb hash R=3 No other pruning. Using PVS of course initial window -infinite,infinite other windows work for my draughtsprog but not for my chessprog. 00:00 27 (0) 1 -0.00 e4xd5 Qd8xd5 d4xe5 Qd5xe5 Bf1-e2 00:00 31 (0) 1 0.01 d4xe5 d5xe4 Qd1xd8 Ke8xd8 00:00 49 (0) 1 0.01 Ng1-f3 d5xe4 Nf3xe5 00:00 76 (0) 1 0.07 Nb1-c3 00:00 257 (0) 2 0.06 Nb1-c3 Nb8-c6 d4xe5 d5xe4 Qd1xd8 Ke8xd8 00:00 991 (0) 3 0.06 Nb1-c3 Nb8-c6 d4xe5 d5xe4 Qd1xd8 Ke8xd8 ++ d4-e5 00:00 1660 (0) 3 0.49 d4xe5 d5xe4 Qd1xd8 Ke8xd8 Nb1-c3 00:00 3764 (0) 4 0.49 d4xe5 d5xe4 Qd1xd8 Ke8xd8 Nb1-c3 00:00 9851 (0) 5 0.06 d4xe5 d5xe4 Qd1xd8 Ke8xd8 Nb1-c3 Nb8-c6 00:00 29220 (0) 6 0.27 d4xe5 d5xe4 Qd1xd8 Ke8xd8 Nb1-c3 Nb8-c6 Bc1-f4 00:01 71305 (0) 7 0.22 d4xe5 d5xe4 Qd1xd8 Ke8xd8 Bc1-g5 f7-f6 e5xf6 g7xf6 Bg5-e3 00:04 186666 (0) 8 0.56 d4xe5 d5xe4 Qd1xd8 Ke8xd8 Nb1-c3 Nb8-c6 Bc1-f4 Bc8-f5 Bf 1-c4 00:10 442847 (0) 9 0.43 d4xe5 d5xe4 Qd1xd8 Ke8xd8 Nb1-c3 Nb8-d7 Bc1-g5 Bf8-e7 Bg 5xe7 Ng8xe7 Ra1-d1 Kd8-e8 00:22 969920 (0) 10 0.46 d4xe5 d5xe4 Qd1xd8 Ke8xd8 Nb1-c3 Nb8-c6 Bc1-f4 Bc8-f5 B f1-c4 Kd8-e8 e5-e6 01:16 3219133 (0) 11 0.62 d4xe5 d5xe4 Qd1xd8 Ke8xd8 Nb1-c3 Kd8-e8 Nc3xe4 Bc8-f5 Bf1-b5 c7-c6 Bb5-d3 Nb8-d7 02:19 6124647 (0) 12 0.55 d4xe5 d5xe4 Qd1xd8 Ke8xd8 Nb1-c3 Nb8-c6 Bc1-f4 Bc8-f5 O-O-O Kd8-e8 Nc3-b5 Ra8-c8 e5-e6 f7xe6 Bf4xc7 >Hi, > >I posted a couple of messages about move ordering yesterday and wanted to share >some results from my (limited) testing. I ended up implementing the suggested >"apparently losing captures" (MVV/LVA) after all others order. In one test >position this resulted in a tree 200k nodes larger at 8 ply but in two others it >resulted in a marginally smaller (under 40k nodes) tree at 8 ply. I will do >more testing on this matter but it may be a moot point because I intend to write >a SEE pretty soon. > >I also did some experimenting with ordering captures that take the last moved >enemy piece. At low search depth this seems to make some difference but at >higher depth this heuristic actually grew the tree in all three test positions I >tried. > >I also did some playing with history weight and settled on hist[x][y] += (2 << >depth). My numbers (this is total nodes searched until ply x including plys >1..x-1) for d2d4 d7d5 e2e4 e7e5 are currently: > >1. 45 >2. 621 >3. 3725 >4. 14146 >5. 38694 >6. 183449 >7. 598020 >8. 1286875 > >I am doing null move (R=2/3 depending on remaining and normal futility pruning >with a slightly larger than safe window on frontier nodes and in qnodes. I've >read about extended futility pruning and razoring too. I'd be interested in >other ideas to cut down the tree search size... be they other move ordering Using less pruning i need 10 times less nodes. >heuristics or other pruning methods that are reasonably safe. How do the nodes >searched in the position given compare to other engines? > >Thanks again, >Scott
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.