Author: Volker Böhm
Date: 11:44:55 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
Without material I get the following analyze:
SpikeR WB2 35 MB:
1 00:00 -3,80 1. b3b2 d2b2
1 00:00 0,00 1. h7h6
2 00:00 0,00 1. h7h6 e3e4
3 00:00 0,00 1. h7h6 e3e4 2. f5e4 f3e4 3. h6h5
4 00:00 0,00 1. h7h6 e3e4 2. f5e4 f3e4 3. h6h5 e4d5
5 00:00 0,00 1. h7h6 e3e4 2. f5e4 f3e4 3. h6h5 e4d5 4. c4c3
6 00:00 0,00 1. h7h6 e3e4 2. f5e4 f3e4 3. h6h5 e4d5 4. c4c3 d2d3 5. c3b2
6 00:00 0,50 1. c4c3 b2c3 2. b3c3 d2a2 3. c3c2 a2c2 4. d3c2
6 00:00 1,00 1. c4c3 b2c3 2. b3c3 d2a2 3. c3c2 a2a1 4. c2h2
7 00:00 0,50 1. c4c3 b2c3 2. b3c3 d2a2 3. c3c2 a2a1 4. c2h2 e3e4
7 00:00 0,00 1. c4c3 b2c3 2. b3c3 e3e4 3. c3a3 e4e5 4. f6g7 f3e3 5. a3c3
8 00:00 0,00 1. c4c3 b2c3 2. b3c3 e3e4 3. c3a3 e4e5 4. f6g7 f3e3 5. a3c3
d2d3
9 00:00 0,00 1. c4c3 b2c3 2. b3c3 e3e4 3. c3a3 e4e5 4. f6g7 f3e3 5. a3c3
d2d3 6. c3d3 e3d3 7. g7h8
10 00:00 0,00 1. c4c3 b2c3 2. b3c3 e3e4 3. c3a3 e4e5 4. f6g7 f3e3 5. a3c3
d2d3 6. c3d3 e3d3 7. g7h8 h2h3
11 00:00 0,00 1. c4c3 b2c3 2. b3c3 e3e4 3. c3a3 f3e3 4. f5e4 e3e4 5. f6g7
d2d3
12 00:00 0,00 1. c4c3 b2c3 2. b3c3 e3e4 3. c3a3 f3e3 4. f5e4 e3e4 5. f6g7
d2d3 6. a3d3 e4d3 7. g7h8 d3e4 8. h8g7 h2h3
12 00:01 0,50 1. b3b2 d2b2 2. c4c3 b2b6 3. f6g7 b6b7 4. g7h6 b7b6 5. h6h5
b6b7 6. c3c2 b7h7 7. h5g6 h7c7 8. d3d2 c7c6 9. g6f7 c6f6 10. f7f6
12 00:01 2,50 1. b3b2 d2b2 2. c4c3 b2b6 3. f6g7 b6b7 4. g7h6 b7b6 5. h6h5
b6b7 6. c3c2 b7h7 7. h5g6 h7c7 8. d3d2 c7c6 9. g6h5 c6h6 10. h5h6
12 00:01 2,80 1. b3b2 d2b2 2. c4c3 b2b6 3. f6g7 b6b7 4. g7h6 b7b6 5. h6h5
b6b7 6. c3c2 b7h7 7. h5g6 h7c7 8. d3d2 c7c6 9. g6h5 c6c2 10. d2d1q c2e2
13 00:02 2,80 1. b3b2 d2b2 2. c4c3 b2b6 3. f6g7 b6b7 4. g7h6 b7b6 5. h6h5
b6b7 6. c3c2 b7h7 7. h5g6 h7c7 8. d3d2 c7c6 9. g6h5 c6c2 10. d2d1q c2e2 11. h5h6
14 00:06 3,10 1. b3b2 d2b2 2. c4c3 b2b6 3. f6f7 b6b7 4. f7e8 b7b8 5. e8d7
b8b7 6. d7c6 b7h7 7. c3c2 h7h8 8. d3d2 h8c8 9. c6b7 c8c2 10. d2d1q c2e2 11. d1a1
14 00:07 3,80 1. b3b2 d2b2 2. c4c3 b2b6 3. f6f7 b6b7 4. f7e8 b7b8 5. e8d7
b8b7 6. d7c6 b7h7 7. c3c2 h7h8 8. d3d2 h8c8 9. c6b7 c8c2 10. d2d1q c2e2 11. d1a1
e3e4
15 00:11 3,80 1. b3b2 d2b2 2. c4c3 b2b6 3. f6f7 b6b7 4. f7e8 b7b8 5. e8d7
b8b7 6. d7c6 b7h7 7. c3c2 h7h8 8. d3d2 h8c8 9. c6b7 c8c2 10. d2d1q c2e2 11. d1a1
e3e4 12. a1a3 f3g2
16 00:13 3,80 1. b3b2 d2b2 2. c4c3 b2b6 3. f6f7 b6b7 4. f7e8 b7b8 5. e8d7
b8b7 6. d7c6 b7h7 7. c3c2 h7h8 8. d3d2 h8c8 9. c6b7 c8c2 10. d2d1q c2e2 11. d1a1
e3e4 12. a1a3 f3g2 13. f5e4
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.