Author: Volker Böhm
Date: 11:43:16 05/28/04
Go up one level in this thread
On May 28, 2004 at 05:32:26, Uri Blass wrote:
>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
No its much easier. Remember that allways returning 0 from eval will lead to
perfect beta cuttoff. Every Nullmove will hit, 100% first cutoffs, ... It´s a
little bit the same with only material.
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.