Author: Uri Blass
Date: 12:02:44 05/28/04
Go up one level in this thread
On May 28, 2004 at 14:43:16, Volker Böhm wrote:
>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
No
You forget that I have pruning that is based on evaluation so I do not expect it
to see it in 12 plies with only material evaluation and no change in the search.
Uri
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.