Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: The key to improving a program

Author: Uri Blass

Date: 15:58:40 05/27/04

Go up one level in this thread


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





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.