Author: Miguel A. Ballicora
Date: 12:12:47 12/06/00
Go up one level in this thread
On December 05, 2000 at 15:46:15, Robert Hyatt wrote: > >Try this position: > >/k/3p/p2P1p/P2P1P///K/ w > >The solution is Kb1, and should take between 18 plies and maybe 21-22 plies >to find. If you can't get to 18 instantly, your hashing is not working right. >For comparison, on a 550mhz single cpu machine, Crafty can reach depth 34 in >8.2 seconds... I tried it and did not work. (it eventually finds the solution after a long time). I found a bug (silly but nasty!) that justifies most of the problem. I was storing "depth-1" when I should have been storing "depth" In pseudo code this was the bug: int search(position_t position, int depth) { hash_hit = retrieve ( hashsig(position), &depthstored, &valuestored... ); if (hash_hit && depthstored >= depth) return valuestored /*in hash table*/; ... loop until I find a cutoff or run out of moves { makemove(move); value = search (position, depth-1); unmakemove(move); ... compare value with best, alpha and beta. } ... hashtable_stored (hashsig(position), depth-1 /*BUG!!!!!*/ etc.); return best } Now the program reaches ply 23 in less than a second but it does not find the solution even when I disabled NULLMOVE. I went to sleep and it found it overnight, though. There are *NOT* many things that can go wrong here!!! Are they?. I am almost sure that the problem I have is the way I handle draw by repetition but I have to test it (and I will have to think of a solution which might not be trivial). I think is not right to store in the hashtable a value returned after a search that hit a move repetition. I'll try to explain what I mean whit this scheme: Moves m1 m2 m3 m4 m5 m6 m7 m8 Ply --> 1 -> 2 -> 3 ->(4)-> 5 -> 6 -> 7 -> 8 | * ^ ^ | | Position 4 is repeated. | m3' | so, in ply 7 I store "DRAW" \___ 3'__ 4'__/ (reached after move = m8). Alternativee path where postion 4' is different than 4. This is a problem, because I can reach, say, postion "7" through and alternative path without passing through position "4". Then, when I am in position "7" I hit the hashtable saying that it is a DRAW by repetition when If I play m8 I don't repeat any position! At least the plan is to get it right with this position... no null move evaluation = material evaluation. Maybe the hashing is ok, but do you think that how move repetition is handled could cause an apparent bug in the hashing? I think so. This morning, before I left to work, I disabled move repetition detection. It reached ply 23 (still Kb2) in less time that it took me to hit enter and look at the screen, but the, it hit a "wall". Ply 24 takes forever and I left. Tonight I will do more tests with the repetition detection. Hopefully I'll get it right. Thanks, Miguel
This page took 0.01 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.