Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 8/28/84; site lll-crg.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!ut-sally!ut-ngp!lll-crg!brooks From: brooks@lll-crg.ARPA (Eugene D. Brooks III) Newsgroups: net.bugs,net.unix,net.lang.c,net.math Subject: Re: Bug in rand() and srand() Message-ID: <433@lll-crg.ARPA> Date: Mon, 4-Mar-85 21:54:58 EST Article-I.D.: lll-crg.433 Posted: Mon Mar 4 21:54:58 1985 Date-Received: Thu, 7-Mar-85 04:22:02 EST References: <320@cubsvax.UUCP> Organization: Lawrence Livermore Labs, CRG group Lines: 22 Xref: watmath net.bugs:559 net.unix:3839 net.lang.c:4637 net.math:1875 > In attempting to use these functions under 4.1bsd on a VAX/780, I found that > rand() returns strictly alternating even and odd numbers, regardless of > seed!!! So I went and tried the same thing on a 4.2bsd system, and found > the same behavior. > > It may be that this has already been hashed out in some > of the above newsgroups, but since I only read net.lang.c among them I will > have missed the discussion. If anyone has a rewritten rand(), or other > advice, I'd appreciate being mailed a fix. > > Thanks, Peter S. Shenkin, {philabs,cmcl2!rna}!cubsvax!peters rand uses a 32bit multiplicative random number generator. These generators tend to generate a repeating sequence in the lower bits. On the pdp 11 the generator used a long and the returned value was shifted right by 16 bits to get an int. The horribly behaved lower bits never hit the user. On the vax the how 32 bit item is returned. As you noticed those badly behaved bits are there. If you want to use rand shift it down. Shift at least 8 bits out. A better way around the problem is to use the more sophisticated random number generator random() all of its bits are supposed to be random and its really not that much slower than rand(). A simple #define rand random can fix your code.