Author: David Rasmussen
Date: 06:17:39 12/05/01
Go up one level in this thread
On December 05, 2001 at 08:18:19, Sune Fischer wrote: >On December 05, 2001 at 07:49:39, David Rasmussen wrote: > >>I will count them if you want me to (when I get around to it :), but I don't >>really see the point. > >The point is, that if you have millions of positions, then I would _expect_ the >kind of collision numbers you talk about. >Right now I don't even know if we agree or not, it depends on this number >entirely. It's only if it is very low that 32 bits will work. > That's all true. But I'm not asking "why doesn't this work". I am assuming that people think that 32-bits is ok for chess, and I'm indeed asking "are you sure that there isn't a problem with this, such as hitting too many different positions for this to be a good idea, because I am seeing collisions". >>Even if there is a lot of positions or even if I have >>overlooked something, the fact still remains that a bogus value is returned from >>the pawn evaluation when such a collision occur. Do you disagree with that? > >It sounds right, but are you positive that it should return the same score? >I mean what if you have changed from midgame evaluation to endgame evaluation >(if you do something like that), then you can't expect the new eval eval() to >match an old one. There could be all sort of these changes in the evaluation (or >search) as the game develops, it's too complicated for me to say. That's a good point but I have disabled all asymmetry. >Instead compare if the 32 bit keys are identical when the 64 keys differ, then >that would have been a collision. > Sure, but that would be a little harder to implement than the experiment I'm doing now. The important thing is that we want to be able to actually tell different positions apart. I have now rerun the experiment but with the change that I also check some of the data that is stored in the table, that is _not_ dependant on anything (such as asymmetry og game phase) other than the pawn structure itself (such as the 8-bit bitboards of which files contain white pawns, likewise for black pawns, the 8-bit bitboards of files with passed pawns). And the collision rate is the same. This test is even stronger, as it positively says that the position that was hashed here was definately not the same position as this one, because they have pawns on different files. The rate seems to be exactly the same, and as I felt pretty sure that I had accounted for asymmetries and gamephases in the first place, this new experiment only confirms that. >>I'm >>not only talking about Chezzz here, but also about Crafty. I haven't heard of >>anybody else in here making the same experiment with their programs, and >>reporting the results. Maybe the results are similar for all programs that use >>32-bit keys. That is what I suspect. > >Yes, I too would like someone else (someone more hardcore;) to frase their >opinion here, couldn't hurt... :) > >>>>And whether this rate is "high" or "low", I don't know. Until I >>>>am sure it is not "too high", I will stick with a rate of zero. Your argument >>>>that there is about 1% chance of collision per game is all well and good. It >>>>just doesn't matter, since Crafty have more than 1 collision a second with appx. >>>>150 kn/s from the initial position. I am asking several questions: > >>You don't comment on this. Why? It is pretty essential :) > >If you really get 300 collisions out of say 10000 positions, then that has to >hurt. However I don't think that is what happening at all. > >-S. If there _are_ collisions, those 10000 positions (if that is even a reasonable number, I assume it is), are getting overwritten pretty often. So why don't you believe that this is what is happening? /David
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.