Author: Uri Blass
Date: 02:32:26 05/28/04
Go up one level in this thread
On May 28, 2004 at 05:31:20, Uri Blass wrote:
>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
I mean that I guess that with more materialistic evaluation it is going to be
harder.
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.