Author: Albert Silver
Date: 13:20:17 06/18/01
Go up one level in this thread
On June 18, 2001 at 15:46:13, Bas Hamstra wrote:
>On June 18, 2001 at 13:05:38, Robert Hyatt wrote:
>
>>On June 18, 2001 at 10:51:12, Bas Hamstra wrote:
>>
>>>On June 18, 2001 at 08:33:21, Ulrich Tuerke wrote:
>>>
>>>>On June 18, 2001 at 08:28:08, Bas Hamstra wrote:
>>>>
>>>>>On June 17, 2001 at 01:09:50, Robert Hyatt wrote:
>>>>>
>>>>>>On June 16, 2001 at 22:59:06, Vincent Diepeveen wrote:
>>>>>>
>>>>>>>Hello,
>>>>>>>
>>>>>>>From Gian-Carlo i received tonight a cool version of crafty 18.10,
>>>>>>>namely a modified version of crafty. The modification was that it
>>>>>>>is using a small sense of Singular extensions, using a 'moreland'
>>>>>>>implementation.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>Instead of modifying Crafty to simulate Deep Blue, why didn't you
>>>>>>modify Netscape? Or anything else? I don't see _any_ point in
>>>>>>taking a very fishy version of crafty and trying to conclude _anything_
>>>>>>about deep blue from it...
>>>>>>
>>>>>>Unless you are into counting chickens to forecast weather, or something
>>>>>>else...
>>>>>
>>>>>I don't agree here. It is fun. Maybe not extremely accurate, but it says
>>>>>*something* about the efficiency of their search, which I believe is horrible. I
>>>>>think using SE and not nullmove is *inefficient* as compared to nullmove. We
>>>>>don't need 100.0000% accurate data when it's obviously an order of magnitude
>>>>>more inefficient.
>>>>
>>>>May be you are right, if the program is running on a PC. However if you can
>>>>reach a huge depth anyway because of hardware, may be you can afford to use
>>>>this, because it doesn't matter too much wasting one ply depth ?
>>>
>>>I don't see why inefficiency becomes less of a problem at higher depths.
>>>Nullmove pruning reduces your effective branching factor to 2,5 where brute
>>>force gets 4,5. So you could suspect at higher depths the difference in search
>>>depths grows, starting with 2 ply, up till how much, 5 ply?
>>
>>Several things here. First a normal alpha/beta program does _not_ have a
>>branching factor of 4.5... it is roughly sqrt(n_root_moves) which is closer
>>to 6.
>
>Not at all. Have you never tried Crafty without nullmove? See below my engine
>output, rootposition. Where is the 6? I have never had 6, in my opinion 4,5 on
>average is normal.
>
>Hash 8 Mb
>PawnHash 4 Mb
>Hashing 524288 positions
>PHash 65536 records
>Evaluation learning 50
>Could not open Tao.bk for input
>Ok[book]
>Book[No]
>Ok[analyze]
>TargetTime set[4750]
> 1. 25 0 25 d2d4
> 2 0 0 52 d2d4 d7d5
> 2. 0 0 91 d2d4 d7d5
> 3 27 0 173 d2d4 d7d5 c1g5
> 3. 27 0 661 d2d4 d7d5 c1g5
> 4 -2 0 1219 d2d4 d7d5 c1g5 g8f6
> 4. -2 0 2206 d2d4 d7d5 c1g5 g8f6
> 5 22 0 4611 d2d4 d7d5 g1f3 c8f5 c1g5
> 5. 22 0 13223 d2d4 d7d5 g1f3 c8f5 c1g5
> 6 0 0 24494 d2d4 d7d5 g1f3 c8f5 c1f4 g8f6
> 6 8 1 52306 e2e4 e7e5 g1f3 g8f6 f1c4 b8c6
> 6. 8 1 64702 e2e4 e7e5 g1f3 g8f6 f1c4 b8c6
> 7 19 2 185234 e2e4 d7d5 e4d5 d8d5 g1e2 c8g4 d2d4
> 7. 19 3 311857 e2e4 d7d5 e4d5 d8d5 g1e2 c8g4 d2d4
> 8 11 6 686116 e2e4 b8c6 d2d4 d7d5 e4d5 d8d5 g1f3 c8f5
> 8. 11 9 978711 e2e4 b8c6 d2d4 d7d5 e4d5 d8d5 g1f3 c8f5
>Ok[quit]
>
>>Second, if you look at DB's log files for the kasparov match, you will find
>>their branching factor is well below 4.0...
>
>So 4 is close to normal, I would say.
>
>>>Of course nullsearch has holes, but they are certainly not big enough to offset
>>>a couple of plies, or none would use nullmove! In practice a n ply nullmove
>>>search sees more than a n-2 ply BF search.
>>>
>>>Keeping that in mind, give Crafty 1000x faster hardware. It would search at
>>>least 20 ply (normally 13 average according to Bob plus at least 7). I can tell
>>>you DB does not search 18 ply BF. Therefore Crafty would in principle see more,
>>>given the same eval. The SE thing only makes it worse.
>>
>>Again, I can tell you that DB did search 16-18 plies deep. We have that in
>>the log files and as direct quotes from the team members. If you can get that
>>deep without null-move, is another couple of plies _really_ worth all the
>>nonsense that null-move search causes? zugzwang problems. fail high/fail low
>>problems. Tactical oversights. Etc.
>
>Not convincing. Several times you have said deeper is better, and there is no
>"tactical barrier". I agree. And nullmove gets you there which is more important
>than the sideeffects. What evidence do you have that beyond 15 ply suddenly
>different laws apply?
Didn't Heinz recently publish a paper on diminishing returns?
Albert
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.