Author: Uri Blass
Date: 07:26:40 12/08/02
Go up one level in this thread
On December 08, 2002 at 10:00:51, Sune Fischer wrote: >On December 08, 2002 at 08:53:46, Uri Blass wrote: > >>On December 08, 2002 at 07:13:51, Sune Fischer wrote: >> >>>On December 08, 2002 at 06:00:24, David Rasmussen wrote: >>> >>>>On December 07, 2002 at 13:54:56, Sune Fischer wrote: >>>> >>>>> >>>>>Well it's still a good idea to do the test, because you detect a small portion >>>>>when only validating the hash move. Anyway it shouldn't be more than a few lines >>>>>inserted into the hash probe. >>>>> >>>>>#define ChopOff(x) (x&0xffffffffffff0000) // ie try with 48 bits >>>>> >>>>>if (current_key!=draft_key) >>>>> if (ChopOff(current_key)==ChopOff(draft_key)) >>>>> Collisions++; >>>>> >>>>> >>>> >>>>First of all, it should be >>>> >>>>#define ChopOff(x) ((x)&0xffffffffffff0000) // ie try with 48 bits >>>> >>>>Not using parenthesis on all levels in preprocessor macros, will get you into >>>>trouble sooner og later. >>> >>>Yes, you are right, my macros all have the parenthesis' around non constants >>> >>>> Of course, I would never use the preprocessor if I >>>>could avoid it (and I almost always can). In this case, since I am using C++, I >>>>would make a typesafe inline function instead (which is one of the many many >>>>reasons I am using C++ instead of C). >>> >>>Right again, I am currently getting rid of most of my macros and doing things >>>the inlined way. I am considering doing this to the "MOVE" also, but dang it is >>>a big rewrite. >>> >>>>That aside, what do you hope to accomplish by such code? You count how many >>>>times the upper 48 bits of a 64 bit signature are the same for different >>>>signatures. That's not interesting. >>> >>>This is precisely what is interesting, because it would tell you how often a 48 >>>bit key would have collided when a 64 bit won't. >>>Of course they might _both_ collide, but I think we agree that there is a very >>>small chance of a 64 bit collision, so you can use the 64 to validate the >>>correctness of the key. >>> >>>>I use the whole signature for comparison in >>>>my hash entries so the upper 48 bits are not interesting to me. Such a count >>>>just shows how many collisions I _would_ have (at least) if I used 48 bit >>>>signatures instead of 64 bit signatures. I don't. >>> >>>Actually the point is you don't need 64 bits, which the test will show you :) >>>I save 4 bytes per hash entry because I am willing to accept 1 collision every >>>10-50 games or something in that ballpark. I know the probability of this >>>causing a bad score and move is neglible compared to the win I get by having a >>>more dense hash. Considering the noise you always have on nullmove, razoring, >>>evaluation and what not, it becomes overkill to store the whole key, IMHO. >>> >>>-S. >> >>I think that if you think about the future when the hardware is going to be >>faster it may be better to have 64 bit key. > >It's not really a hardware issue here, I know I will still be packing moves to >16 bits for storage in the hash when hardware is native 64 bit. The point is that when you are going to have better hardware you may have more collisions because of bigger hash tables and faster hardware. > >>Today 48 bit key may be better but I do not consider maybe 3 elo improvement >>that programs may get from using 48 bit instead of 64 bit as very important. > >Well 3 elo here and 3 elo there, it all adds up. >Three elo is still more than the 0.001 elo you lose because of a collision every >10th game :) every 10th game is only for today and things may be worse in the future and I do not want to change things today only to change them back later. I already have things that I need to change in the future(for example I use integers for the history table and when the hardware gets to be faster this may lead to bad order of moves because these numbers can be bigger than 2^32). I know that crafty has the same problem. It is not good for long analysis and in the future(maybe in 2010 or 2015) it is not going to be good for tournament games. 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.