Author: Volker Böhm
Date: 22:48:35 05/27/04
Go up one level in this thread
On May 27, 2004 at 18:58:40, Uri Blass wrote:
>On May 27, 2004 at 18:32:50, Volker Böhm wrote:
>
>>On May 27, 2004 at 15:12:47, James Swafford wrote:
>>
>>>On May 26, 2004 at 11:52:31, Volker Böhm wrote:
>>>
>>>>The following helps and are not mentioned allready:
>>>>
>>>>1. add a flag or a compiler option to remove any pruing or extending code from
>>>>your search. The result should be a perft command! I think it is very powerful
>>>>to be able to check the real movegen and search with this test.
>>>>
>>>>2. WAC Test-Positions. Very simple position. If you can´t find the result you
>>>>have a bug or other problems (ca. 10 positions need eval, all others should be
>>>>found without eval very fast).
>>>
>>>What 10 positions do you think require eval? I ask because I'm
>>>not getting 290 with an "almost material only" eval at 10/sec mv
>>>on a 1.6 ghz machine.
>>>
>>>--
>>>James
>>
>>>
>>>
>>>
>>>>
>>>>3. Build a standard tournament with about 8 engines with littel more strength an
>>>>2 engines of much lower strength. Play 200 games (20 against each engine) after
>>>>each relevant change. Allways use the same 200 opening position (example to
>>>>depth 10), disable book. Compare the results to older tests.
>>>>
>>>>4. Build a functionality to debug your search tree. I think a simple log-file is
>>>>not a good soloution. I suggest to add code whitch is able to "follow" a given
>>>>variant. And dont forget to print the node count at every position so you can
>>>>add a break point if this node count is reached.
>>>>
>>>>5. Look at the node count if you change eval. Most eval changes that increases
>>>>node count in a bunch of good test positions will have bugs. I am not really
>>>>able to explain but in most cases this holds true.
>>>>
>>>>Greetings Volker
>>
>>Sorry to answer a little late:
>>Those positions are not solved by spike in 10 sec. with ONLY material (don´t add
>>any eval but material because "some eval" could increase solve time!) or it took
>>some time > 2 sec. to solve them. All others are solved in <= 2 sec.
>>
>> 86) .. Nf6-g4 a7-a6 (passed-pawn code needed)
>>100) b5-b6 b5-b6 * 4 Seconds (depth 20)
>>152) Nc3-e4 Nc3-d5 (needs depth 12 and 0:27 to find)
>>180) .. Nf6xd5 Nf6-e8 ("just" positional)
>>230) .. Rb7-b4 a5-a4 (pawn-wall code needed)
>>248) .. Qd6-c5 Qd6-c5 * 6 Seconds (depth 11)
>>264) .. Ra8-b8 Rd8xd4 (needs depth 11 and 1:20 to find)
>>297) .. Bc6xg2, Bd6xh2 Bc6-a8 (needs depth 10 and 0:23 to find)
>>
>>CPU is a celeron 1,2 GHZ.
>>
>>Position 152, 264, 297 could be possible hints for improvements of search to me!
>>
>>Greetings Volker
>
>I am surprised about position 2 Rxb2 that is not a problem that is supposed to
>be solved in less than 2 seconds with only material evaluation.
>
>Uri
Don´t understand why. Spike will find material gain with depth 12 (+ 2,50) in 1
sec. Never had a Problem with this one. Spike uses Check, Recapture and Pawn on
Row 7 extensions and qSearch is checking promotions.
Volker
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.