[kw-pm] Seeding srand

Wed Feb 9 09:38:00 PST 2011

On 02/09/2011 08:07 AM, Max wrote:
> Changing the seed won't really affect the output distribution.  That
> would seem to be a limitation in rand().

IMHO, the problem here is that you are xoring a large 32bit value by a
small 16 bit value. So you're reducing the likely seeds rather than
creating more varied seeds.

Check out these plots of likely seeds:

time() ^ $$

http://softwareprocess.es/z/hist-time-xor-pid.pdf
http://softwareprocess.es/z/plot-time-xor-pid.pdf
( that pattern should bother you)

time() * $$

http://softwareprocess.es/z/hist-time-mult-pid.pdf
http://softwareprocess.es/z/plot-time-mult-pid.pdf
( that pattern should give you a little more confidence )

Note how the histogram table for the 2nd one is spread across many
values, while the xor concentrates into certain buckets. This means many
of the srand bits are the same and some of the values are the same.

The limitation here is how often one calls srand and how many calls
calls to rand you make. $$ doesn't have great range and is probably very
deterministic. If you call this script many times in the same seconds
the distribution of the pids. I'd argue that you are reducing the likely
seeds by xoring by the pid. XOR is not a good operation for this, it
doesn't have any magic to it either. If you look at naive random
functions they usually use something like multiplies and shifts to
distribute the bits about.

Generate the table:

perl -e '$start=1297271306;$pid=$$;for($start..($start+3600)){ print
$_^$pid," ",0xFFFFFFFF & $_*$pid,$/; $pid++; }' > k

Using R:

v <- read.table("k")
v$Xor <- v$V1
v$Mult <- v$V2
plot(v$Xor,v$Mult)
plot(v$Xor)
plot(v$Mult)
pdf("plot-time-xor-pid.pdf")
plot(v$Xor)
dev.off()
pdf("plot-time-mult-pid.pdf")
plot(v$Mult)
dev.off()
pdf("hist-time-mult-pid.pdf")
hist(v$Mult)
dev.off()
pdf("hist-time-xor-pid.pdf")
hist(v$Xor)
dev.off()

> stem(v$V1)

  The decimal point is 3 digit(s) to the right of the |

  1297257 |
11111111111111111111111111111111111111111111111111111111111111111111+407
  1297258 |
00000000000000000000000001111111111111111111111111111111111111111111+294
  1297259 |
  1297260 |
  1297261 |
  1297262 |
  1297263 |
  1297264 |
00000000000000000000000000000000000000000000000000000000000000000000+585
  1297265 |
33333333333333333333333333333333333333333333333333333333333333333333+665
  1297266 |
00000000000000000000000000000000000000000000000000000000000000000000+585
  1297267 |
  1297268 |
11111111111111111111111111111111111111111111111111111111111111111111+585

> stem(v$V2)

  The decimal point is 8 digit(s) to the right of the |

   0 |
00011111111122222222333333334444444445555555556666666677777777788888+83
   2 |
00000000001111111222222223333333344444444455555555566666666777777788+88
   4 |
00000000011111122222222333333333344444444455555555666666667777777788+88
   6 |
00000000111111112222222233333333344444444455555555666666677777777788+88
   8 |
00000001111111122222222233333333344444444555555556666666677777777788+87
  10 |
00000000011111111222222222333333333444444555555556666666667777777778+88
  12 |
00000000111111112222222223333333344444444555555556666666667777777778+87
  14 |
00000000111111111122222222233333334444444455555555566666666777777778+89
  16 |
00000000111111111222222222333333334444444555555555666666666777777888+87
  18 |
00000000111111111122222222333333334444444455555555566666666677777788+88
  20 |
00000000011111111122222223333333344444444455555555566666667777777888+87
  22 |
00000000011111111222222222333333334444444445555555566666666677777778+89
  24 |
00000000011111112222222223333333344444444455555555666666667777777788+87
  26 |
00000001111111112222222223333333334444444445555555666666667777777778+88
  28 |
00000000111111111222222223333333334444444455555555666666667777777778+85
  30 |
00000000011111111122222222233333333344444445555555556666666677777777+88
  32 |
00000000001111111122222222233333334444444445555555556666666677777777+88
  34 |
00000000011111111222222222333333334444444445555555566666666677777777+88
  36 |
00000000001111111122222223333333334444444445555555566666666677777778+88
  38 |
00000000111111112222222233333333334444444455555555566666667777777778+88
  40 |
00000000111111112222222223333333334444444455555555566666667777777778+87
  42 |
00000000111111112222222223333333333444444445555555666666666777777777+5

> 
> 
> On 2/9/2011 11:02 AM, Robert Pike wrote:
>> Trying to get a good seed value for an app I'm working on. The app
>> will be running on both windows and linux. The rand function will only
>> be looking at numbers between 0 and 3 (inclusive).
>> Right now I'm using time ^ $$. The funny thing is when I run on one
>> server the results skew "greatly" towards the extremes (i.e. 0 or 3 -
>> slighly more than 75% of the random numbers generated are 0 or 3). On
>> another server the number 3 has never gotten hit after over 200 trial
>> runs. Both servers are Windows machines.
>> Appreciate any feedback anyone can give. Thanks.
>>
>>
>> _______________________________________________
>> kw-pm mailing list
>> kw-pm at pm.org
>> http://mail.pm.org/mailman/listinfo/kw-pm
> 
> _______________________________________________
> kw-pm mailing list
> kw-pm at pm.org
> http://mail.pm.org/mailman/listinfo/kw-pm

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://mail.pm.org/pipermail/kw-pm/attachments/20110209/9db950df/attachment.bin>