Author: Uri Blass
Date: 02:23:58 09/23/01
Go up one level in this thread
On September 23, 2001 at 04:33:14, Helmut Conrady wrote: >On September 22, 2001 at 22:17:06, Uri Blass wrote: > >>On September 22, 2001 at 19:08:06, Torstein Hall wrote: >> >>>On September 22, 2001 at 18:29:46, Andreas De Troy wrote: >>> >>>>When I see results for the so called "Fritzmarks", I notice that the actual >>>>numbers decrease with increasing hashtables. Is this an artefact of the >>>>measurement? In other words, are larger hashtables always better? I suppose it >>>>depends of the speed of the processor. If you have, for instance an Athlon 1 Ghz >>>>(or a 1.5 Ghz or...), does it -in general- make sense to increase the size of >>>>the hashtables to 256 Mb, 512 Mb or more? >>>> >>>>Thanks in advance for any help! >>> >>>It also depends on your time settings. For long time analysis I think very big >>>Hashtables are always a bonus. >>> >>>Torstein >> >>I am not sure about it. >>There is a danger of hash collision and this problem can become more important >>if the hash tables are bigger and it is possible that part of the programmers >>did not care about very big hash tables+ very long time control+future hardware. >> >>The problem is that programs can assume that 2 different positions are the same >>because their 64 bit number is the same when it is not truth(I also believe that >>there are programs that use less than 64 bits and in this case they may have >>problems earlier). >> >>If the hash tables are very big then the probability for hash collision can >>increase and if there are enough hash collisions the result can be a bad move. >> >>Uri > >BTW: Stefan Meyer-Kahlen said, he had never seen a hash collision during his >many years work in programming. > >Helmut It may be possible to learn about it if programmers check what happens if they use less bits for hash signature. I am sure that there are hash collisions if programs use 16 bits signature or 32 bits signature and the question is what is the optimal size of hash tables for every number of nodes per move at these conditions. note that hash collision does not mean always that the program is going to play a bad move because I believe that changing the score of one random node usually does not change the move and we usually need to change the score of more nodes in order to change the move when the program searches deeper so practically I believe that even if we know in theory that there is an average of 1 hash collision every game it may change the move choice only in a small part of the games. I do not know if 1/10,1/100 or 1/1000 because I did not investigate this problem and I do not know if somebody investigated it. Uri
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.