Way for computing random primes in standard C.

**Jordan Abel** · Feb 28 '06, 04:45 PM

Re: Way for computing random primes in standard C.

On 2006-02-28, Flash Gordon <spam@flash-gordon.me.uk> wrote:[color=blue]
> Keith Thompson wrote:[color=green]
>> Jordan Abel <random832@gmai l.com> writes:[color=darkred]
>>> On 2006-02-28, Keith Thompson <kst-u@mib.org> wrote:[/color]
>> [...][color=darkred]
>>>> C99 7.20.2.2p2 says:
>>>>
>>>> The srand function uses the argument as a seed for a new sequence
>>>> of pseudo-random numbers to be returned by subsequent calls to
>>>> rand. If srand is then called with the same seed value, the
>>>> sequence of pseudo-random numbers shall be repeated. If rand is
>>>> called before any calls to srand have been made, the same sequence
>>>> shall be generated as when srand is first called with a seed value
>>>> of 1.
>>>>
>>>> Note the phrase "a new sequence". It's possible, but not required,
>>>> that the "new sequence" matches some other sequence at a different
>>>> position. It's also possible that it doesn't. For example, there may
>>>> be no overlap between the sequence created by srand(1) and the one
>>>> created by srand(2) (this is particularly likely if rand()'s internal
>>>> state has more bits than the unsigned int argument to srand()).
>>> Not quite - Let's suppose, naively, that srand() merely initializes a
>>> particular set of bits of rand()'s internal state, and sets the
>>> remaining bits to zero. Now, if at any point in srand(1)'s sequence, the
>>> internal state contains the result of srand(2) [reasonable if it's
>>> "perfect" i.e. cycles through every possible combination of bits the
>>> internal state could have], srand(1) and srand(2) are thus two different
>>> points in the same sequence.[/color]
>>
>> Yes, I think you're right.
>>
>> Suppose rand() has N bits of internal state. If it cycles through all
>> 2**N possible internal states, then you can think of the set of all
>> states as a closed loop with 2**N nodes; each call to rand() advances
>> on position along the loop, and each call to srand() jumps to a single
>> point on the loop. (Ideally the points for different values of
>> srand() are roughly equally spaced along the loop, maximizing the
>> uniqueness of each subsequence.)
>>
>> If the cycle is shorter than 2**N, then the states form some number of
>> disjoint loops rather than one single loop. A call to rand() would
>> advance by one position on a single loop, and a call to srand() could
>> jump to an arbitrary point on any loop.
>>
>> But as you point out, an RNG that cycles through its entire state is
>> probably better than one that doesn't (but one that doesn't is
>> certainly permitted by the standard).[/color]
>
> Here's an idea. Isn't Pi meant to be a non-repeating series of digits?
> See http://www.piworld.de/pi-statistics/ So how about for your PRNG
> calculating the digits of Pi in base RAND_MAX+1?
>
> srand could then just select where to start.
>
> This would not be good enough for security, since if anyone knows that
> it is producing the digits of Pi all they have to do is identify where
> in the sequence you are, but for other uses it should produce an
> infinite (as far as we know) sequence of numbers with very good
> statistical properties.
>
> It might also not be the most efficient method of producing random numbers.[/color]

If RAND_MAX+1 is a power of 2, it could be done (based on the fact that
a formula exists to independently calculate hex digits of pi)

You'd probably want srand() to initialize the upper bits of the state
[said state would be an index into the "digits" in that case] rather
than the lower ones.
[color=blue]
> Note that I am *not* an expert on statistics, Pi, or PRNGs.[/color]

So basically neither of us knows how good it would really be.

**Walter Roberson** · Feb 28 '06, 04:45 PM

Re: Way for computing random primes in standard C.

In article <1141107962.224 007.23810@t39g2 000cwt.googlegr oups.com>,
mensanator@aol. com <mensanator@aol .com> wrote:
[color=blue]
>When it's stated that
> "...the Mersenne Twister as the core generator.
> It produces 53-bit precision floats and has a period of 2**19937-1."[/color]
[color=blue]
>Doesn't it mean that there are 2**19937-1 states and if one were
>to actually call it 2**19937 times, then one would be right back
>where one started regardless of what number srand() was called with?[/color]

Not necessarily.
[color=blue]
>I was not implying that srand(1) and srand(2) have adjacent states.
>But doesn't periodic mean that at whatever state # srand(1) starts in,
>it must eventually reach the same state that srand(2) starts in?[/color]

Not necessarily.

It would be possible to the initial seed to affect parameters
in the PRNG, such that srand(1) and srand(2) each had the same
period, but that the cyles for the two were not the same.

Getting further OT:

It appears to me that the traditional Unix drand48() might be
an instance of this. According to the man page:

The initializer function srand48 sets the high-order 32 bits of Xi
to the 32 bits contained in its argument. The low-order 16 bits of
Xi are set to the arbitrary value 330E16.

and

The value returned by any of the functions drand48, erand48,
lrand48, nrand48, mrand48, or jrand48 is computed by first
generating the next 48-bit Xi in the sequence. Then the
appropriate number of bits, according to the type of data item to
be returned, are copied from the high-order (leftmost) bits of Xi
and transformed into the returned value.

If we put these together, we would see that srand(1) and srand(2)
would have the same cycles -only- if it happened the the linear
congruential generator applied to 0x1330E16 happened to result
in 0x2330E16 at some point. Further analysis would be needed to
see whether that ever happened -- the default multiplier and
constant for drand48() and kin are both even, so it is not
the usual case that "every possible n-bit value will be generated,
eventually".
--
All is vanity. -- Ecclesiastes

**Jordan Abel** · Feb 28 '06, 05:05 PM

Re: Way for computing random primes in standard C.

On 2006-02-28, Ben Bacarisse <ben.usenet@bsb .me.uk> wrote:[color=blue][color=green]
>> As one final comment -- using the ANSI C's rand() is bad because the
>> state size is so small[/color]
>
> 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.[/color]

I think he's referring to the [non-normative] example given in the
standard.

**Nelu** · Feb 28 '06, 05:25 PM

Re: Way for computing random primes in standard C.

Keith Thompson wrote:[color=blue]
> "Nelu" <tandauioan@gma il.com> writes:
> [...][color=green]
> > I'm not into RNGs so I may be wrong about this, but I think Rod's right
> > in a way. The sequence of numbers generated by the RNG is always the
> > same for a given seed. Calling seed repeatedly, using a predefined
> > algorithm can build a new RNGs on top of the existing one. As long as
> > the sequence of calls to seed can be kept secret no one should,
> > theoretically, be able to repeat your sequence. That's mixing known RNG
> > algorithm with an unknown algorithm of reseeding. I think this is the
> > end of him being right.[/color]
>
> I'm no expert on RNGs either, but my understanding is that piling
> arbitrary stuff on top of an existing RNG is not a good approach.
> It's unlikely to give you better results than just using the base RNG
> directly, assuming the RNG was designed at all competently in the
> first place. A given RNG may not be perfect, but arbitrary minor
> tweaks to it will probably make it worse. (I think Knuth writes about
> this.)
>
> If your RNG is good enough, just use it. If it's not good enough, use
> something else.
>[color=green]
> > However, leaving aside the fact that it's unlikely to keep the sequence
> > a secret from a good hacker there are two problems:[/color]
>
> If you want to keep the sequence secret (for cryptography, for
> example), *don't* use rand(). srand() and rand() are specifically
> designed to produce *repeatable* sequences. (And if you want reliable
> advice, ask someone who knows more about this stuff than I do.)
>[/color]
I agree. That's what I was meaning to say starting with 'However' and
the
1 and 2 points :-).

--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)

**mensanator@aol.com** · Feb 28 '06, 06:25 PM

Re: Way for computing random primes in standard C.

Walter Roberson wrote:[color=blue]
> In article <1141107962.224 007.23810@t39g2 000cwt.googlegr oups.com>,
> mensanator@aol. com <mensanator@aol .com> wrote:
>[color=green]
> >When it's stated that
> > "...the Mersenne Twister as the core generator.
> > It produces 53-bit precision floats and has a period of 2**19937-1."[/color]
>[color=green]
> >Doesn't it mean that there are 2**19937-1 states and if one were
> >to actually call it 2**19937 times, then one would be right back
> >where one started regardless of what number srand() was called with?[/color]
>
> Not necessarily.[/color]

Then what does "period" mean?
[color=blue]
>[color=green]
> >I was not implying that srand(1) and srand(2) have adjacent states.
> >But doesn't periodic mean that at whatever state # srand(1) starts in,
> >it must eventually reach the same state that srand(2) starts in?[/color]
>
> Not necessarily.[/color]

Ok.
[color=blue]
>
> It would be possible to the initial seed to affect parameters
> in the PRNG, such that srand(1) and srand(2) each had the same
> period, but that the cyles for the two were not the same.[/color]

Ok, but we can't infer that from the standard, can we?
[color=blue]
>
>
> Getting further OT:
>
> It appears to me that the traditional Unix drand48() might be
> an instance of this. According to the man page:
>
> The initializer function srand48 sets the high-order 32 bits of Xi
> to the 32 bits contained in its argument. The low-order 16 bits of
> Xi are set to the arbitrary value 330E16.[/color]

Isn't 330E16 24 bits?
[color=blue]
>
> and
>
> The value returned by any of the functions drand48, erand48,
> lrand48, nrand48, mrand48, or jrand48 is computed by first
> generating the next 48-bit Xi in the sequence. Then the
> appropriate number of bits, according to the type of data item to
> be returned, are copied from the high-order (leftmost) bits of Xi
> and transformed into the returned value.
>
>
> If we put these together, we would see that srand(1) and srand(2)
> would have the same cycles -only- if it happened the the linear
> congruential generator applied to 0x1330E16 happened to result
> in 0x2330E16 at some point. Further analysis would be needed to
> see whether that ever happened -- the default multiplier and
> constant for drand48() and kin are both even, so it is not
> the usual case that "every possible n-bit value will be generated,
> eventually".
> --
> All is vanity. -- Ecclesiastes[/color]

**Keith Thompson** · Feb 28 '06, 08:35 PM

Re: Way for computing random primes in standard C.

Ben Bacarisse <ben.usenet@bsb .me.uk> writes:[color=blue]
> On Mon, 27 Feb 2006 21:19:19 -0800, websnarf wrote:[/color]
[...][color=blue][color=green]
>> As one final comment -- using the ANSI C's rand() is bad because the
>> state size is so small[/color]
>
> 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.[/color]

Right, but in practice, the common wisdom is that rand() is only
barely adequate, so programs that need high-quality random numbers
don't use it anyway, so there's little motivation for implementers to
improve it.

Also, the standard provides a sample implementation, and many
implementers just use that.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

**Micah Cowan** · Feb 28 '06, 09:05 PM

Re: Way for computing random primes in standard C.

"mensanator@aol .com" <mensanator@aol .com> writes:
[color=blue]
> Walter Roberson wrote:[color=green]
> > In article <1141107962.224 007.23810@t39g2 000cwt.googlegr oups.com>,
> > mensanator@aol. com <mensanator@aol .com> wrote:
> >[color=darkred]
> > >When it's stated that
> > > "...the Mersenne Twister as the core generator.
> > > It produces 53-bit precision floats and has a period of 2**19937-1."[/color]
> >[color=darkred]
> > >Doesn't it mean that there are 2**19937-1 states and if one were
> > >to actually call it 2**19937 times, then one would be right back
> > >where one started regardless of what number srand() was called with?[/color]
> >
> > Not necessarily.[/color]
>
> Then what does "period" mean?[/color]

It means that at some point, it will start over again from the
beginning.

Consider a really dumb PNRG that only ever has a cycle of four
different outputs. Perhaps srand(1) will result in the sequence:

1 6 3 12 1 6 3 12 ...

And srand(2) results in:

4 9 5 3 4 9 5 3 ...

note that they both have a period of four, but the values that are
cycled are completely different.

**Keith Thompson** · Feb 28 '06, 10:35 PM

Re: Way for computing random primes in standard C.

Micah Cowan <micah@cowan.na me> writes:
[...][color=blue]
> It means that at some point, it will start over again from the
> beginning.
>
> Consider a really dumb PNRG that only ever has a cycle of four
> different outputs. Perhaps srand(1) will result in the sequence:
>
> 1 6 3 12 1 6 3 12 ...
>
> And srand(2) results in:
>
> 4 9 5 3 4 9 5 3 ...
>
> note that they both have a period of four, but the values that are
> cycled are completely different.[/color]

The random number generator has at least 8 distinct states (3 bits),
which means it *could* have a cycle of 8 outputs, making full use of
its internal state. For example, srand(1) might result in:

1 6 3 12 4 9 5 3 1 6 3 12 4 9 5 3

and srand(2) might result in:

4 9 5 3 1 6 3 12 4 9 5 3 1 6 3 12

But, as you said, it's a really dumb RNG. Generally speaking, using
only a subset of the available state for a given sequence is allowed
by the standard, but *probably* not a good idea (unless the state is
large enough that a subset of it gives you a very long repeating cycle
anyway).

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

**mensanator@aol.com** · Feb 28 '06, 10:35 PM

Re: Way for computing random primes in standard C.

Micah Cowan wrote:[color=blue]
> "mensanator@aol .com" <mensanator@aol .com> writes:
>[color=green]
> > Walter Roberson wrote:[color=darkred]
> > > In article <1141107962.224 007.23810@t39g2 000cwt.googlegr oups.com>,
> > > mensanator@aol. com <mensanator@aol .com> wrote:
> > >
> > > >When it's stated that
> > > > "...the Mersenne Twister as the core generator.
> > > > It produces 53-bit precision floats and has a period of 2**19937-1."
> > >
> > > >Doesn't it mean that there are 2**19937-1 states and if one were
> > > >to actually call it 2**19937 times, then one would be right back
> > > >where one started regardless of what number srand() was called with?
> > >
> > > Not necessarily.[/color]
> >
> > Then what does "period" mean?[/color]
>
> It means that at some point, it will start over again from the
> beginning.[/color]

Isn't that what I said? The issue HERE is how can a periodic
function NOT return eventually to where it started?
[color=blue]
>
> Consider a really dumb PNRG that only ever has a cycle of four
> different outputs. Perhaps srand(1) will result in the sequence:
>
> 1 6 3 12 1 6 3 12 ...
>
> And srand(2) results in:
>
> 4 9 5 3 4 9 5 3 ...
>
> note that they both have a period of four, but the values that are
> cycled are completely different.[/color]

That applies to the second "Not necessarily." comment,
which I did not dispute.

But can this happen in a PRNG with an n-bit state and a
2**n-1 period? Am I correct in stating that in such a case there
is only ONE sequence and srand() merely positions to a new
starting point in that one sequence? For srand() to cause
completely different sequences don't you need either more
bits in the state or else a different algorithm for each value
passed to srand()?

**Micah Cowan** · Feb 28 '06, 11:05 PM

Re: Way for computing random primes in standard C.

Keith Thompson <kst-u@mib.org> writes:
[color=blue]
> Micah Cowan <micah@cowan.na me> writes:
> [...][color=green]
> > It means that at some point, it will start over again from the
> > beginning.
> >
> > Consider a really dumb PNRG that only ever has a cycle of four
> > different outputs. Perhaps srand(1) will result in the sequence:
> >
> > 1 6 3 12 1 6 3 12 ...
> >
> > And srand(2) results in:
> >
> > 4 9 5 3 4 9 5 3 ...
> >
> > note that they both have a period of four, but the values that are
> > cycled are completely different.[/color]
>
> The random number generator has at least 8 distinct states (3 bits),
> which means it *could* have a cycle of 8 outputs, making full use of
> its internal state. For example, srand(1) might result in:
>
> 1 6 3 12 4 9 5 3 1 6 3 12 4 9 5 3
>
> and srand(2) might result in:
>
> 4 9 5 3 1 6 3 12 4 9 5 3 1 6 3 12[/color]

Yes, but this has nothing to do with the point I was making, which was
to answer the question that was asked:
[color=blue]
> Walter Roberson wrote:[color=green]
> > In article <1141107962.224 007.23810@t39g2 000cwt.googlegr oups.com>,
> > mensanator@aol. com <mensanator@aol .com> wrote:
> >[color=darkred]
> > >When it's stated that
> > > "...the Mersenne Twister as the core generator.
> > > It produces 53-bit precision floats and has a period of 2**19937-1."[/color]
> >[color=darkred]
> > >Doesn't it mean that there are 2**19937-1 states and if one were
> > >to actually call it 2**19937 times, then one would be right back
> > >where one started regardless of what number srand() was called with?[/color]
> >
> > Not necessarily.[/color]
>
> Then what does "period" mean?[/color]

**Micah Cowan** · Feb 28 '06, 11:05 PM

Re: Way for computing random primes in standard C.

"mensanator@aol .com" <mensanator@aol .com> writes:
[color=blue]
> Micah Cowan wrote:[color=green]
> > "mensanator@aol .com" <mensanator@aol .com> writes:
> >[color=darkred]
> > > Walter Roberson wrote:
> > > > In article <1141107962.224 007.23810@t39g2 000cwt.googlegr oups.com>,
> > > > mensanator@aol. com <mensanator@aol .com> wrote:
> > > >
> > > > >When it's stated that
> > > > > "...the Mersenne Twister as the core generator.
> > > > > It produces 53-bit precision floats and has a period of 2**19937-1."
> > > >
> > > > >Doesn't it mean that there are 2**19937-1 states and if one were
> > > > >to actually call it 2**19937 times, then one would be right back
> > > > >where one started regardless of what number srand() was called with?
> > > >
> > > > Not necessarily.
> > >
> > > Then what does "period" mean?[/color]
> >
> > It means that at some point, it will start over again from the
> > beginning.[/color]
>
> Isn't that what I said? The issue HERE is how can a periodic
> function NOT return eventually to where it started?[/color]

Oh, yeah, apparently. Guess I misread again.
[color=blue]
> But can this happen in a PRNG with an n-bit state and a
> 2**n-1 period?[/color]

Actually, I think you mean 2**n period. Use a very small n to consider it.
[color=blue]
> Am I correct in stating that in such a case there
> is only ONE sequence and srand() merely positions to a new
> starting point in that one sequence?[/color]

That seems right to me.
[color=blue]
> For srand() to cause
> completely different sequences don't you need either more
> bits in the state or else a different algorithm for each value
> passed to srand()?[/color]

The second case is essentially the same as the first, I think; but
either way I believe that's a yes.

**Walter Roberson** · Feb 28 '06, 11:15 PM

Re: Way for computing random primes in standard C.

In article <1141107962.224 007.23810@t39g2 000cwt.googlegr oups.com>,
mensanator@aol. com <mensanator@aol .com> wrote:[color=blue]
>When it's stated that
> "...the Mersenne Twister as the core generator.
> It produces 53-bit precision floats and has a period of 2**19937-1."[/color]
[color=blue]
>Doesn't it mean that there are 2**19937-1 states and if one were
>to actually call it 2**19937 times, then one would be right back
>where one started regardless of what number srand() was called with?[/color]

Period is the length of the cycle, but there can be an indefinite
number of states before it enters the cycle.

Trivial example:

static unsigned int just_seeded = 1;
static unsigned int seed = 1;

void srand(unsigned int newseed) {
just_seeded = 1 + (newseed - 1) % 31415;
seed = newseed;
}

int rand(void) {
int new_rand_num
if (just_seeded == 0) {
new_rand_num = /* regular PNRG goes here */
} else {
just_seeded--;
new_rand_num = 42;
}
return new_rand_num;
}

That is, emit 42 between 1 and 31415 times (dependant upon the seed)
before entering into the cycle. When you finally encounter 42
"naturally" you will not be back where you started, and if the period
is 2**19937-1 then after that many calls, you will not be back where
you started either. Indeed, no matter how many calls you make
to rand() without srand(), you never get back where you started
with this particular rand().
--
"law -- it's a commodity"
-- Andrew Ryan (The Globe and Mail, 2005/11/26)

**Walter Roberson** · Feb 28 '06, 11:35 PM

Re: Way for computing random primes in standard C.

In article <1141165472.202 215.298580@v46g 2000cwv.googleg roups.com>,
mensanator@aol. com <mensanator@aol .com> wrote:[color=blue]
>For srand() to cause
>completely different sequences don't you need either more
>bits in the state[/color]

More bits than what? The state is not necessarily restricted
to the number of bits in an unsigned int (i.e., the argument to srand()),
and different arguments of srand() do not necessarily affect the same
state bits in the same way.
[color=blue]
>or else a different algorithm for each value
>passed to srand()?[/color]

static unsigned long m_list[] = { /* list of possible multipliers */ };
static unsigned long c_list[] = { /* list of possible constants */ };
static unsigned long current_m = /* second element of m_list */;
static unsigned long current_c = /* second element of c_list */;
static unsigned long seed = 1;

void srand( unsigned int newseed ) {
seed = newseed;
current_m = m_list[seed % (sizeof m_list / sizeof m_list[0])];
current_c = c_list[seed % (sizeof c_list / sizeof c_list[0])];
}

int rand(void) {
/* insert a LCG with coefficients current_m and current_c */
}

If the sizes of m_list and c_list were mutually prime and the
product of the sizes was greater than UINT_MAX then you would
produce a different PNRG for every possible seed, and yet it
would be exactly the same algorithm for each of them.
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton

**Micah Cowan** · Mar 1 '06, 12:05 AM

Re: Way for computing random primes in standard C.

roberson@ibd.nr c-cnrc.gc.ca (Walter Roberson) writes:
[color=blue]
> In article <1141165472.202 215.298580@v46g 2000cwv.googleg roups.com>,
> mensanator@aol. com <mensanator@aol .com> wrote:[color=green]
> >For srand() to cause
> >completely different sequences don't you need either more
> >bits in the state[/color]
>
> More bits than what? The state is not necessarily restricted
> to the number of bits in an unsigned int (i.e., the argument to srand()),
> and different arguments of srand() do not necessarily affect the same
> state bits in the same way.[/color]

You snipped the answer to your question. More bits than n, to produce
more than one sequence, if one of the sequences has a period of 2**n.

-Micah

**mensanator@aol.com** · Mar 1 '06, 01:35 AM

Re: Way for computing random primes in standard C.

Walter Roberson wrote:[color=blue]
> In article <1141107962.224 007.23810@t39g2 000cwt.googlegr oups.com>,
> mensanator@aol. com <mensanator@aol .com> wrote:[color=green]
> >When it's stated that
> > "...the Mersenne Twister as the core generator.
> > It produces 53-bit precision floats and has a period of 2**19937-1."[/color]
>[color=green]
> >Doesn't it mean that there are 2**19937-1 states and if one were
> >to actually call it 2**19937 times, then one would be right back
> >where one started regardless of what number srand() was called with?[/color]
>
> Period is the length of the cycle, but there can be an indefinite
> number of states before it enters the cycle.
>
> Trivial example:
>
> static unsigned int just_seeded = 1;
> static unsigned int seed = 1;
>
> void srand(unsigned int newseed) {
> just_seeded = 1 + (newseed - 1) % 31415;
> seed = newseed;
> }
>
> int rand(void) {
> int new_rand_num
> if (just_seeded == 0) {
> new_rand_num = /* regular PNRG goes here */
> } else {
> just_seeded--;
> new_rand_num = 42;
> }
> return new_rand_num;
> }
>
> That is, emit 42 between 1 and 31415 times (dependant upon the seed)
> before entering into the cycle. When you finally encounter 42
> "naturally" you will not be back where you started, and if the period
> is 2**19937-1 then after that many calls, you will not be back where
> you started either. Indeed, no matter how many calls you make
> to rand() without srand(), you never get back where you started
> with this particular rand().[/color]

Ok, I accept the "not necessarily" comments.

But if all you have to go by is the standard, the issue remains:

should you call srand() more than once to "improve" the randomness?

I've been trying to justify answering no, but if those justifications
don't necessarily hold, does the answer change to yes, or does it
remain no?

[color=blue]
> --
> "law -- it's a commodity"
> -- Andrew Ryan (The Globe and Mail, 2005/11/26)[/color]

Way for computing random primes in standard C.

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment