Way for computing random primes in standard C.

[fieldfallow]

Hello all,

Is there a function in the standard C library which returns a prime
number which is also pseudo-random?

Assuming there isn't, as it appears from the docs that I have, is there
a better way than to fill an array of range 0... RAND_MAX with
pre-computed primes and using the output of rand() to index into it to
extract a random prime.

Also what is meant by reinitialising the rand() function with srand(1)?
Does it mean that further calls to rand() will return numbers with a new
starting point? If so, how is it different to calling srand() with a
seed value such as that returned by the time() function?

Thank you all for the help. I find this group very useful.

[A. Sinan Unur]

Micah Cowan <mi***@cowan.name> wrote in
news:87************@mcowan.barracudanetworks.com:

"A. Sinan Unur" <1u**@llenroc.ude.invalid> writes:

Micah Cowan <mi***@cowan.name> wrote in

> I don't agree, generally, with what Rod's suggesting, but I was
> trying to at least clarify that his point was rather different from
> what was being claimed by others (Sinan still seems confused, at
> least), and

What am I confused about?

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).

The main reason srand exists is to provide repeatable results in
scientific applications.

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

--
A. Sinan Unur <1u**@llenroc.ude.invalid>
(reverse each component and remove .invalid for email address)

[Pedro Graca]

Walter Roberson wrote:

In article <sl*******************@ID-203069.user.individual.net>,
Pedro Graca <he****@hotpop.com> wrote:

Walter Roberson wrote:

In article <sl*******************@ID-203069.user.individual.net>,
Pedro Graca <he****@hotpop.com> wrote:

Why copy the "Reply-To:" address and not the "From:" one?

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 :)

--
If you're posting through Google read <http://cfaj.freeshell.org/google>

[Pedro Graca]

Vladimir S. Oka wrote:

Pedro Graca wrote:

[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?

--
If you're posting through Google read <http://cfaj.freeshell.org/google>

[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:Th*************@gmail.com>

[David Holland]

On 2006-02-28, Ben Bacarisse <be********@bsb.me.uk> wrote:

On Mon, 27 Feb 2006 21:19:19 -0800, websnarf wrote:

As one final comment -- using the ANSI C's rand() is bad because the
state size is so small

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...

--
- David A. Holland
(the above address works if unscrambled but isn't checked often)