Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: CilkChess question for Don

Author: Don Dailey

Date: 21:51:40 01/31/99

Go up one level in this thread


>>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.


>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



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.