Way for computing random primes in standard C.

[A. Sinan Unur]

From the posts that I've read, and from your recently posted code
(upstream), you were making a case against calling srand() (or more
accurately, after) each call to rand(). However, to my knowledge,
nobody was making a case /for/ such behavior.

I was trying to show the extreme case because I frankly did not have the
patience to run long simulations and subject them to a battery of
statistical tests.

While I am just a practitioner in the field of statistics, and not a
theorist, I think the general principle still holds that my seeding the
PRNG multiple times in a given run, you run the risk of introducing
patterns into the sequence (which may not be detectable to the human,
but may lead to undesirable consequences).

I should have said "the main reason the ability to seed the PRNG
exists".

Hm. Given rand()'s implementation track-record, I can't think of many
scientific applications in which I would be comfortable using it
(though I don't doubt for a moment the truth of what you say).

I was thinking in a slightly more general context than just the stock
rand/srand provided by the library, but more in terms of any PRNG and
its seeder. I did not make that clear. Sorry.

Sinan

 

[Pedro Graca]

[thread hijack]

Does the standard guarantee [numbers generated by rand() are] the
same on all implementations (that have stdlib.h)
On my system (I don't have a compiler for my other OS here at home)
it outputs these numbers:

1804289383
71876166

My numbers above came from a Debian with kernel 2.6.10

Same for me (SUSE Linux 10.0).

With MSDE on Windows XP, the same program outputs
41
175

and RAND_MAX is defined as 32767!

However, the Standard does not prescribe the implementation of rand()
and srand() (7.20.2.2p5). It does, however, give a portable example
implementation, but it's by no means required to be used.

Of course, D'oh! Why would RAND_MAX be implementation defined and not a
constant defined withing the standard itself otherwise?

 

[Pedro Graca]

It was automatic by my newsreader.

So it's not a mis-configuration ... Don't know if that's better than an
unusual auto-configuration

 

[Kenneth Brody]

Keith Thompson wrote:
[...]

(You can get your own PDF copy of the C99 standard plus TC1 and TC2;
google "n1124.pdf".)

Thanks for the pointer.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[David Holland]

>
> I don't think the standard mandates any state size, does it? I don't
> think there is nothing to stop rand() being a very high quality generator.

Historically, srand() returned the state of the generator in an
unsigned int, and allowed you to restart or resume sequences by
passing that value back to srand(). This is obviously incompatible
with a high-quality implementation, which is why the BSD world got
random() and srandom().

Said usage of rand() seems to be thoroughly deprecated and nearly
forgotten nowadays, although traces can still be found. Feeding
"return the old seed" to Google yields quite a few variants of the old
BSD random(3) man page's discussion of the issue.

Nonetheless, on a lot of platforms rand() still gets you a low-quality
generator. Always check the documentation...