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.