Author: Robert Hyatt
Date: 02:51:03 08/13/98
Go up one level in this thread
On August 12, 1998 at 23:19:21, Bernhard Bauer wrote: >On August 12, 1998 at 05:52:50, Robert Hyatt wrote: > >>On August 11, 1998 at 23:13:03, Bernhard Bauer wrote: >> >>> >>>I suppose you have used your latest version of crafty and it is really good >>>news. It sounds that you have overcome that nasty null move problem. >>>Congratulations! >>> >> >>no... my point was that any 15.x should repeat this. The only changes in 15.18 >>are evaluation changes. The search is identical to the past few versions. No >>changes for null-move, no changes in ordering or extensions, nothing. The only >>pieces of code that are different are evaluation-related... > >I disagree. >To my knowledge *no* version of crafty up til now was able to solve this >position. Definitely not v. 15.15 anv not 15.17 as I showed you. On the other >hand seting DO_NULL=0 and NO_NULL=1 solves this position in about 2 min. >So it is not completely unreasonable to think its a null move problem. > >>If older versions couldn't find this, it is either (a) hashing (b) evaluation >>bugs or (c) something else... null-move does effect the search in odd ways, >>but I don't see how it is a problem here as this isn't really about zug as much >>as it is about sufficient depth with extensions... >> >I have noticed that changing the hash size may change the results sometimes >in a random manner and it looks to me that there are still several bugs in >crafty. Of course you may be right that it is not a null move problem but I >think the position is a zug position. > >>15.18 will be out soon, once I am sure the evaluation is back under control and >>it is playing reasonably again. So far, so good, but I'm looking carefully... >> >Good luck and keep on the good work > >Kind regards > >Bernhard Then I have no explanation for why 15.18 solves this. However, one new thing is that 15.18 suddenly has problems with win at chess 169. Older versions got this very quickly, the new version now takes an extra ply, with no changes to the search whatsoever. Hashing is primarily a random number-driven algorithm anyway, and changing the size will change the results significantly, and no, I don't think there are any bugs in the hashing code at all... but you can take the well-known basic chess endings position 70 (aka fine #70) and run it with different hash sizes and get significant variation in the depth where it solves it. Most versions will get this at 18 plies with the default hash table size, but increasing or decreasing hash size will change this by 5-6 plies... because what gets overwritten and what "survives" depends on the random hash addresses that get generated... normal, but a pain...
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.