Author: Robert Hyatt
Date: 07:17:40 02/01/99
Go up one level in this thread
On February 01, 1999 at 00:51:40, Don Dailey wrote: >>>Testing the move is like adding 2 or 3 bits (I'm guessing, but it's >>>some small number of bits) to the hash key. It's a really good way >>>to measure false matches in the hash table. If you can spare about 3 >>>bits or so, you can pick up the majority of conflicts in the hash table. >>>With 3 bits, you will identify a false match almost 90% of the time. >>>It's a neat trick and testing the move is pretty much the same >>>idea, except you get the bits for free since you store the move >>>anyway. But it turns out that I don't test the move, I generate >>>all the moves and push this one to the front if I run across it, >>>similar to how one might do the killers. I could trivially do >>>your test though and probably should. Technically, I should probably >>>try the hash move before doing any work but I never found this to be >>>worth anything for me. Is this what you do? I think it's because >>>there is rarely a hash move near enough to the end nodes to do you >>>much good. >>> >> >> >>I _must_ validate the move... because I search this move before generating >>moves. And if it isn't valid, my program 'blows up'. Because making a bad >>move will corrupt the board, and I make/unmake which means I might _really_ >>corrupt it on the unmake (ie if I try O-O where it isn't legal, the board is >>_gone_ because the MakeMove() gives me a new king and rook, and the UnMake >>won't fix it... > >My program will also crash and burn if an illegal move is attempted. >But I will never make an illegal move, even if it is in the hash >table. Essentially, the validation process is to sort it to the >top IF it is already in the list. Since you try the move first >of course you have to validate it. But do you find that this >speeds things up in a measurable way? I don't do this because >I never noticed a speedup. if you don't get a speedup, your 'hash-move' stuff sounds like it isn't working. Because shouldn't that move cause an instant fail-high in a reasonable percentage of the cases? And in those cases, I do _no_ move generation at all, and save that time. I haven't tried measuring this in Crafty, but in Cray Blitz, we didn't generate any moves in about 1/3 of the positions we searched, normally, although in endgames this went _way_ up... > > >>And I _know_ about the probability of a hash collision with 64 bits. It is >>guaranteed to happen multiple times per game... now the question is are things >>going to crash or not? In many cases, the hash move is still legal, which is >>surprising... but I can't stand the alternative, because once I screw up I am >>'done' for that game... >> >>I got zapped in one game in Cape May the last ACM event, because I had turned >>the 'validity check' off not thinking.... > >We had an assertion failure during one tournament I am embarassed to admit. >I am embarassed for two reasons, the debugging should have been turned >off, and the program should not have failed. It was one of those >castling bug things. The assertion picked up the error fortunately, >it would have been tough finding this one without the assertion. >It was a very beautiful bug though. Every assumption and test about >castling failed due to a rare set of circumstances that had to happen all >together in order to produce the bug. It was beautiful like a composed >chess problem. The program was restarted and fortunately the bug did >not occur again and I fixed it after the game was over. But if the >bug had continued to occur, we would have lost the game unless the >tournament director had allowed a recompile and I doubt he would have. > > >- Don I just lost, because the 'illegal move' corrupted the board, and made CB enter an infinite fail-high loop. This bug was caused by our new singular extension code going crazy in a king-and-pawn-only ending and extending us out to our max of 64 plies and then some... which caused me to store a bogus move in the hash table..
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.