Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Crafty 16.7

Author: Robert Hyatt

Date: 05:21:35 06/01/99

Go up one level in this thread


On June 01, 1999 at 07:52:17, Bernhard Bauer wrote:

>On June 01, 1999 at 06:32:05, Bernhard Bauer wrote:
>
>>On June 01, 1999 at 02:18:27, Eugene Nalimov wrote:
>>
>>>1. Chess program searches much faster when one move is significally better than
>>>all others - there are a lot of cutoffs in the tree, "fast" evaluation is
>>>sufficient, null move works almost each time, etc.
>>>
>>>2. Crafty 16.6 sees right move in that position early because of the poor moves
>>>ordering. When it started to consider the right move, it's effective search
>>>depth is much higher, because to necesary information is stored in the hash
>>>table. And it's stored there because program earlier evaluated (and discarded) a
>>>line that resulted in the same board position.
>>>
>>>3. Due to the modifications made in parallel search in 16.8 (it splits tree at
>>>the root, if I remember it correctly), it now considers right move *before*
>>>considering the bad move that nevertheless stores necessary information in the
>>>hash tables.
>>>
>>>4. So, till ply 26, 16.8 has no move that is much better than all other moves.
>>>That is why it takes 16.8 much longer to go to some depth compared to 16.6.
>>>
>>>Eugene
>>>
>>
>>Practically that means that you cannot use Crafty 16.8 with mt>1 for solving
>>this type of position since Crafty 16.8 cannot find usefull data in the hash
>>table and will *not* give the solution move back in reasonable time.
>>
>>Here I give 4 other positions of the same type. Their solution relays hevily
>>on the use of hash tables.
>>
>>F. Sackmann, 1913  FEN: 8/8/2p/k1p1K/p1P/P/8/8 w
>>M. Botwinnik, 1939 FEN: 8/1k/p/p2p2K/P2P/8/8/8 w
>>C. Locock, 1892    FEN: 6k/3p/3p/3P/4P1p/6P/8/K w
>>C. Locock, 1892    FEN: 6k/3p/3p/3P/4P1p/6P/8/K b
>>
>>Enjoy.
>>Kind regards
>>Bernhard
>>
>
>I'd like to add some results for the above positions for Crafty 16.6
>and Crafty 16.8 running on one processor (mt=1) which show, that it's *not*
>only the parallel search modification leading to worse results.
>Crafty had 2 min/pos. The ply number is the number of full (completed) plies.
>
>                      ply   time  score  move
>F. Sackmann  16.6      34   1:25   9.70  Kf5 good
>             16.8      24   1:42   2.16  Kf5 good
>
>                      ply   time  score  move
>M. Botwinnik 16.6      25   2.89   1.73  Kf5 good
>             16.8      24   39.02  1.26  Kf5 good
>
>                      ply   time  score  move
>C. Locock    16.6      32   1:25   3.95  Kb1 good
>             16.8      25   1:22   0.37  Kb2 bad
>
>                      ply   time  score  move
>Fine 70      16.6      31   2.94   3.21  Kb1 good
>             16.8      28   1:58   3.13  Kb1 good
>
>So some doubts still remain for the sequential search, at least for my
>executables running on my system.
>
>Kind regards
>Bernhard


This is true for _every_ version.  Change the eval, you change the shape of
the tree.  16.8 has significant eval changes...  find a tactical problem and
you'll see no change at all usually... but when you find positional test
positions, the eval can change things drastically with only small changes to
the eval code itself...



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.