Author: Robert Hyatt
Date: 07:59:59 10/30/03
Go up one level in this thread
On October 30, 2003 at 10:09:04, Vincent Diepeveen wrote: >On October 30, 2003 at 09:44:48, Robert Hyatt wrote: > >>On October 29, 2003 at 13:39:03, Vincent Diepeveen wrote: >> >>>On October 28, 2003 at 23:03:31, Robert Hyatt wrote: >>> >>>In general combining 2x32 goes wrong, so you shouldn't give this tip to him Bob! >> >>In general, it works _perfectly_. This is not hard to prove mathematically. >> >>Particularly when we need less than 1000 random numbers for Zobrist hashing. > > >If you simply combine 2 numbers of 32 bits by the microsoft RNG then you will >find multilineair problems. So? You are adding yet another constraint that nobody had to start with. I said "with my Numerical Recipes" RNG." But for Zobrist hashing, the MS rng will work just fine. You only need a total of 768 RNG's. I don't know of any 32 bit RNG with a period that short, or that produces badly non-random numbers in the first 1500 numbers. Even the old C library random(), ran() and rand() calls work just fine there, although I suggest using the one in Crafty's source as it is a known good generator with a very long period. > >You admitted this yourself years ago. > >Then it was: "but you shouldn't use 32 bits microsoft stuff but 48 bits or 64 >bits *nix stuff" There is no 48 or 64 bit *nix stuff that I am aware of... And I never said to not use microsoft stuff, because I have never used it myself... > >I see therefore massive handwaving again here. So do I, but _not_ from me... > >It is the difference between neat and bad programming again. > >With bad programming you can get a working program too, you realize that? In this case it doesn't matter. Just take the first 1500 numbers from any RNG you want and test them with the usual RNG test suite, for runs, uniformness, poker test, whatever test you want. They'll pass. And the first 1500 is all you need to solve _this_ problem. If we were talking about a two billion iteration Monte Carlo simulation, the answer would be different. But we are talking about 1500 random variates. > >> >>> >>>If generalized over the average 32 bits PRNG and generate 64 bits hash numbers >>>with it like this, then you end up with multilineair connection and many >>>collissions. >> >>Not for 1000 numbers, again. Do the test. _then_ report the results. I > >I already did this test years ago and posted it here. > >There was a collission every 200000 nodes then. Then you had a _lousy_ implementation. I have _always_ constructed my 64 bit numbers from a pair of 32 bit numbers. I have tested them. For randomness. For hamming distance average. And for collisions. I have _never_ seen anyone report 1 collision for 200M nodes, with a 64 bit number. And I do mean _never_. In my test, run on a machine with huge memory, I added a 32 byte field to the hash table, which contained the actual board position, 4 bits per square. When I got a hash match, I checked the actual position. I ran with this for a couple of weeks on ICC. And I didn't get a collision per _game_, where all the games were 60 30 type games. At about 500K nodes per second back then. From recent tests, 1 collision per game will not make any difference whatsoever to a program's performance. In fact, one collision per 1000 nodes will not make significant difference. And this is not from guessing, it is from running a _bunch_ of tests. > >When i used 64 bits numbers that dropped to once each 200 million nodes. > >Later i started using more bits out of that 64 and it is safe now. I have no idea what that means. you used more bits out of 64 bits and you compared that to using 64 bits? That's uninterpretable to me. You either use 64 bit numbers or you use less than 64 bits. > >>have done this. Several of us tested our random numbers a few years ago. The > >Yes it was me testing it. You did *not*. > >You never posted onto this subject. > >Like most programmers i did an experiment here and the average combination of 2 >* 32 bits is just plain *incorrect*. > >>RNG from Numerical Recipes that I use is _very_ good. Particularly when I need >>less than 2000 32-bit values to make less than 1000 64 bit numbers. > >>I've run _real_ tests using my random numbers. You can find my results, >>Bruce's results, and John Stanback's results posted on r.g.c.c several years >>ago. I saw less than one collision per 3 hours of searching. That can >>be ignored easily. > >*you saw*, you *remember*. > >But you never used the 'average' RNG here. In fact you *did* use the average RNG >in the past but it didn't work very well combining 2 x 32 bits. > >Yet you did not draw that conclusion. Someone else did for you. That's why >Gijsbert Wiesenekker has created the RNG for Crafty. > >For the supercomputer i of course had to retest things again as things work >differently there. So my last test is from around 8 hours ago. > >>> >>>Now i'm sure you will show up with something that doesn't have multilineair >>>connection, but that's not what i call the 'average' 32 bits RNG :) >> >>I have _always_ cited my RNG as an adequate solution to the problem. It > >*your* RNG? > >May i beg your pardon? > >You didn't even WRITE all that code in crafty. > >Gijsbert Wiesenekker did. > >>is an "average RNG" that was published in the book "Numerical Recipes" 20+ >>years ago. > >>>It's like saying using 'goto' is ok in a programming environment. Where this is >>>certainly true, it should not be a policy to do so :) >> >> >>Eh? _every_ program you write has goto's. (aka jumps). They are not >>bad. In fact, they are _unavoidable_. > >goto is faster in some cases, because of the imperfection of compilers. > >It doesn't change neat programming concepts. > >Yet knowing your program uses inline assembly everywhere, it's no surprise that >you fall that low. > > >>>>On October 28, 2003 at 21:29:18, Vincent Diepeveen wrote: >[snip]
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.