Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: The key to improving a program

Author: Uri Blass

Date: 02:31:20 05/28/04

Go up one level in this thread


On May 28, 2004 at 01:48:35, Volker Böhm wrote:

>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

Latest Movei also does it at depth 12 with evaluation(I have no version with no
positional evaluation at this moment) but getting depth 12 is not something that
is possible to get in 1 second and it needs more than 7 million nodes for it.

12 106 2459 5063063 b3b8 d2g2 h7h5 h2h4 b8b7 g2d2 b7g7 e3e4 f5e4 f3e4 g7g1 e4e3
 f6f5
12 107 3338 7153201 b3b2
12 136 3655 7975896 b3b2
12 213 4230 9213060 b3b2 d2b2 c4c3 b2b6 f6g7 b6b7 g7h6 b7b6 h6h5 b6b5 c3c2 b5f5
 h5h4 f5f6 h7h5 f6c6 d3d2 c6c2 d2d1q c2e2 d1d5 e3e4
12 213 4252 9254570 b3b2 d2b2 c4c3 b2b6 f6g7 b6b7 g7h6 b7b6 h6h5 b6b5 c3c2 b5f5
 h5h4 f5f6 h7h5 f6c6 d3d2 c6c2 d2d1q c2e2 d1d5 e3e4

I guess that without mainly material evaluation it is going to be harder because
movei is using the evaluation function to prune lines and without a bonus for
pawns in the 7th it may prune the correct line in the middle as not logical
based on 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.