On Sun, 2 Feb 2003, Andrey A. Chernov wrote:
On Sun, Feb 02, 2003 at 17:30:48 +, Mark Murray wrote:
Why not? Arc4 is a) deterministic and b) good for all bits.
If you mean arc4random() function - not, because it use true randomness,
if you mean RC4 algorithm, probably yes, but we
On Sun, 2 Feb 2003 [EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED], Andrey A. Chernov writes:
On Sun, Feb 02, 2003 at 19:32:50 +0100, [EMAIL PROTECTED] wrote:
Anyway, last time we discussed this, I think we stuck with the rand()
we had because we feared that people were using it's
On Sun, 2 Feb 2003, Juli Mallett wrote:
* De: David Malone [EMAIL PROTECTED] [ Data: 2003-02-02 ]
[ Subjecte: Re: rand() is broken ]
On Sun, Feb 02, 2003 at 02:37:25PM -0800, Steve Kargl wrote:
FreeBSD Redhat SunOS
660787754660787754645318364
FWIW - AIX
On Mon, Feb 03, 2003 at 21:40:20 -0800, David Schultz wrote:
followed by a 5 or 6. There is a similar pattern for 'e a 7'. I
think this pretty much demonstrates that the algorithm isn't good
enough to generate high-quality randomness with respect to
different seed values. I'm not
On Tue, Feb 04, 2003 at 12:46:59 +0300, Andrey A. Chernov wrote:
Returning to current algorithm, I am interested in good NSHUFF value in
the range 100-2000. Do you have any findings there?
Apparently 100 is not enough too, I see repeated pattern in your
program. I'll try other values...
--
On Tue, Feb 04, 2003 at 12:46:59 +0300, Andrey A. Chernov wrote:
So, if you define USE_WEAK_SEEDING and re-compile rand.c, you'll get even
worse results from your test. It means current variant is better then
previous. If you know even better algorithm wich pass restrictions above,
just tell
On Tue, Feb 04, 2003 at 12:58:40 +0300, Andrey A. Chernov wrote:
On Tue, Feb 04, 2003 at 12:46:59 +0300, Andrey A. Chernov wrote:
Returning to current algorithm, I am interested in good NSHUFF value in
the range 100-2000. Do you have any findings there?
Apparently 100 is not enough
Thus spake Andrey A. Chernov [EMAIL PROTECTED]:
On Mon, Feb 03, 2003 at 21:40:20 -0800, David Schultz wrote:
I don't try to make rand() good for high-quality pseudo-randomness,
because it can be done by price of speed and, more important, big state
size. Due to rand_r() restriction state size
On Tue, Feb 04, 2003 at 03:52:37 -0800, David Schultz wrote:
You can do better than the present generator with 32 bits of state.
See the following page by Neal Wagner (not to be confused with David Wagner):
http://www.cs.utsa.edu/~wagner/laws/rng.html
The section on LCGs suggests that
On Tue, Feb 04, 2003 at 15:07:30 +0300, Andrey A. Chernov wrote:
On Tue, Feb 04, 2003 at 03:52:37 -0800, David Schultz wrote:
You can do better than the present generator with 32 bits of state.
See the following page by Neal Wagner (not to be confused with David Wagner):
David Schultz [EMAIL PROTECTED] writes:
You can do better than the present generator with 32 bits of state.
See the following page by Neal Wagner (not to be confused with David Wagner):
http://www.cs.utsa.edu/~wagner/laws/rng.html
The attached patch, based on one of the m/k pairs
On Tue, Feb 04, 2003 at 14:00:27 +0100, Dag-Erling Smorgrav wrote:
David Schultz [EMAIL PROTECTED] writes:
You can do better than the present generator with 32 bits of state.
See the following page by Neal Wagner (not to be confused with David Wagner):
On Tue, Feb 04, 2003 at 16:10:06 +0300, Andrey A. Chernov wrote:
On Tue, Feb 04, 2003 at 14:00:27 +0100, Dag-Erling Smorgrav wrote:
David Schultz [EMAIL PROTECTED] writes:
You can do better than the present generator with 32 bits of state.
See the following page by Neal Wagner (not to be
On Tue, Feb 04, 2003 at 16:17:48 +0300, Andrey A. Chernov wrote:
On Tue, Feb 04, 2003 at 16:10:06 +0300, Andrey A. Chernov wrote:
On Tue, Feb 04, 2003 at 14:00:27 +0100, Dag-Erling Smorgrav wrote:
David Schultz [EMAIL PROTECTED] writes:
You can do better than the present generator with
Andrey A. Chernov [EMAIL PROTECTED] writes:
There is one bug in your patch: 0 is still illegal, so my fix required.
I believe that's a feature. All linear congruence generator have a
fixed point. 0 is a far better fixed point than any other because it
is more obviously unsuited (for some
On Tue, Feb 04, 2003 at 16:28:45 +0300, Andrey A. Chernov wrote:
I'll produce working variant based on your patch...
When all done correctly, there is repeated pattern still, so some NSHUFF
drop required too:
1 7 e 4 a 0 7 d 3 a 0 6
See attached patch based on -current sources.
--
Andrey
Andrey A. Chernov [EMAIL PROTECTED] writes:
And the next bug is 32bit overflow there:
tmp = *ctx * 62089911;
Ack, I thought the type promotion was automatic. Updated patch is
attached.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
Index: lib/libc/stdlib/rand.c
On Tue, Feb 04, 2003 at 14:43:57 +0100, Dag-Erling Smorgrav wrote:
I believe that's a feature. All linear congruence generator have a
fixed point. 0 is a far better fixed point than any other because it
is more obviously unsuited (for some values of obviously) as a
seed value. (but see
On Tue, Feb 04, 2003 at 16:47:14 +0300, Andrey A. Chernov wrote:
On Tue, Feb 04, 2003 at 16:28:45 +0300, Andrey A. Chernov wrote:
I'll produce working variant based on your patch...
When all done correctly, there is repeated pattern still, so some NSHUFF
drop required too:
1 7 e 4 a
Andrey A. Chernov [EMAIL PROTECTED] writes:
With NSHUFF 100 situation not changed much, so I beleive that stated
problem is common for this type PRNGs, so we gains nothing changing
formulae to Knuth-recommended values.
Yes we do. We get a better sequence for any given seed, i.e. we get
less
Andrey A. Chernov [EMAIL PROTECTED] writes:
On Tue, Feb 04, 2003 at 14:43:57 +0100, Dag-Erling Smorgrav wrote:
All that being said, adding 1 to *ctx before returning it (see patch)
adresses both of your objections: a seed of 0 will not cause the LCG
to get stuck, and the result of rand()
On Tue, Feb 04, 2003 at 15:23:28 +0100, Dag-Erling Smorgrav wrote:
Andrey A. Chernov [EMAIL PROTECTED] writes:
On Tue, Feb 04, 2003 at 14:43:57 +0100, Dag-Erling Smorgrav wrote:
All that being said, adding 1 to *ctx before returning it (see patch)
adresses both of your objections: a seed
On Tue, Feb 04, 2003 at 15:22:03 +0100, Dag-Erling Smorgrav wrote:
Yes we do. We get a better sequence for any given seed, i.e. we get
less correlation between n and x(n) for any given x(0). I don't think
it changes much for long sequences, but we get a better distribution
for short
On Tue, Feb 04, 2003 at 17:36:04 +0300, Andrey A. Chernov wrote:
with a != 0 values are monotonically increased, I try with
a == 123459876
With your a == 62089911 (i.e. +1) the same:
0: 62089911
1: 124179822
2: 186269733
3: 248359644
4: 310449555
5: 372539466
6: 434629377
7: 496719288
8:
FWIW - AIX aggrees with Solaris.
Endiannes, or an SVR4 implementation difference?
OS X agrees with FreeBSD i386. In fact, FreeBSD sparc64 and FreeBSD
alpha are all the same too, so it seems the code isn't too sensitive
to byteorder or wordsize.
Bakul's comments on who agrees with BSD
* De: David Malone [EMAIL PROTECTED] [ Data: 2003-02-03 ]
[ Subjecte: Re: rand() is broken ]
FWIW - AIX aggrees with Solaris.
Endiannes, or an SVR4 implementation difference?
OS X agrees with FreeBSD i386. In fact, FreeBSD sparc64 and FreeBSD
alpha are all the same too, so
On Sun, Feb 02, 2003 at 16:26:39 -0800, David Schultz wrote:
The correlation is still present with your patch and NSHUFF set to
10. For instance, try seeding rand() with contiguous monotonically
increasing integers, and observe the four lowest-order bits.
Since you already have running
At 4:41 PM -0800 2003/02/02, Terry Lambert wrote:
Donald Knuth seemed to like them well enough to publish the
algorithm, as part of his discussion on randomness. He *didn't*
publish RC4, in that same discussion.
RC stands for Ron's Code. This stuff came after the work that
Diffie
FWIW - AIX aggrees with Solaris.
OSF1 .. V5.1 732 alpha
HP-UX . B.11.00 U 9000/800
agree with Solaris
--
Alexander Pohoyda
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Andrey A. Chernov writes:
If I understand correctly, this still doesn't solve the problem,
because any PRNG sequence that hits the magic value will still get
stuck there forever.
It was true for the first patch I post which just move problem to another=
place (this is commonly spreaded
On Mon, Feb 03, 2003 at 10:55:42 +, Mark Murray wrote:
How do you _know_ that your newly chosen magic number isn't going to cause
some kind of recurring (and too-short) sequence of numbers?
I run simple test for it, it is not too short.
--
Andrey A. Chernov
http://ache.pp.ru/
To
On Mon, Feb 03, 2003 at 14:08:41 +0300, Andrey A. Chernov wrote:
On Mon, Feb 03, 2003 at 10:55:42 +, Mark Murray wrote:
How do you _know_ that your newly chosen magic number isn't going to cause
some kind of recurring (and too-short) sequence of numbers?
I run simple test for it, it
Andrey A. Chernov writes:
On Mon, Feb 03, 2003 at 10:55:42 +, Mark Murray wrote:
How do you _know_ that your newly chosen magic number isn't going to cause
some kind of recurring (and too-short) sequence of numbers?
I run simple test for it, it is not too short.
simple test?
How
On Mon, Feb 03, 2003 at 11:19:17 +, Mark Murray wrote:
simple test?
How long did you check for?
See my another message with details.
random() is documented to not repeat before some number of outputs;
how do you know that this fix does not significantly shorten that?
random(3) is
On Mon, Feb 03, 2003 at 14:26:00 +0300, Andrey A. Chernov wrote:
random(3) is not affected to to its hashing nature. We talk about rand(3).
to to = due to
--
Andrey A. Chernov
http://ache.pp.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of
This is final fix for 1st value correlation problem. Somebody with
math statistic knowledge please run some test to be sure that NSHUFF is
good enough for this simple PRNG (i.e. not 100% good, but good for average
quality PRNG we have). My simple test shown that 100 is enough, but I
am not
I'm afraid I don't understand the fix... and how it
seems to affect the historical behaviour of srand()/rand().
How does it address the understanding that if I use
srand(28), I will get exactly the same sequence of
numbers srand(28) produced yesterday, last week,
last year?
I have worked with
On Mon, Feb 03, 2003 at 07:01:50 -0500, Thomas David Rivers wrote:
Please, oh please, don't change that behavior in
srand()/rand().
This subject is not discussed (again). We already discuss it long time ago
and agrees that changes are allowed especially when they fix bugs. Search
mailing
On Mon, Feb 03, 2003 at 07:01:50AM -0500, Thomas David Rivers wrote:
I'm afraid I don't understand the fix... and how it
seems to affect the historical behaviour of srand()/rand().
How does it address the understanding that if I use
srand(28), I will get exactly the same sequence of
numbers
Thus spake Thomas David Rivers [EMAIL PROTECTED]:
I'm afraid I don't understand the fix... and how it
seems to affect the historical behaviour of srand()/rand().
How does it address the understanding that if I use
srand(28), I will get exactly the same sequence of
numbers srand(28) produced
Bakul Shah [EMAIL PROTECTED] writes:
Guys, please realize that random() is also used in generating
simulation inputs (or timing or whatever). If you go change
the underlying algorithm or its parameters one can't generate
the same sequence from the same seed when repeating a test.
Some chip
Brad Knowles wrote:
At 4:41 PM -0800 2003/02/02, Terry Lambert wrote:
Donald Knuth seemed to like them well enough to publish the
algorithm, as part of his discussion on randomness. He *didn't*
publish RC4, in that same discussion.
RC stands for Ron's Code. This stuff came
Thus spake Andrey A. Chernov [EMAIL PROTECTED]:
On Sun, Feb 02, 2003 at 16:26:39 -0800, David Schultz wrote:
The correlation is still present with your patch and NSHUFF set to
10. For instance, try seeding rand() with contiguous monotonically
increasing integers, and observe the four
David Schultz ([EMAIL PROTECTED]) wrote:
Rather than me showing you more semi-meaningful numbers from
Marsaglia's tests, why don't you look at the following sequence,
which I get by taking the lowest four bits of the 201st number in
the rand() sequence for seeds of (0, 1, 2, ...).
f c 9 6
Thus spake Eric Hodel [EMAIL PROTECTED]:
David Schultz ([EMAIL PROTECTED]) wrote:
Rather than me showing you more semi-meaningful numbers from
Marsaglia's tests, why don't you look at the following sequence,
which I get by taking the lowest four bits of the 201st number in
the rand()
On Sat, Feb 01, 2003 at 23:06:50 -0800, Kris Kennaway wrote:
FreeBSD's rand() implementation has been broken for the past 23
months, since the following commit:
i.e. the first value returned from rand() is correlated with the seed
given to srand(). This is a big problem unless your seed is
On Sun, Feb 02, 2003 at 12:04:22PM +0300, Andrey A. Chernov wrote:
Yes, first value correlation is there, but old formulae have even worse
effect The random sequences do not vary much with the seed, as source
file comments and whole discussion about old RNG bad effects shown. I.e.
for
On Sun, Feb 02, 2003 at 01:11:06 -0800, Kris Kennaway wrote:
Another problem (noticed by tjr) is that once the sequence hits '0' it
jumps to INT_MAX and stays there forever. For example, seeding with
srand(0) produces nothing but INT_MAX from rand().
It looks like a lot more validation of
In message [EMAIL PROTECTED], Andrey A. Chernov writes:
--SUOF0GtieIMvvwua
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Feb 02, 2003 at 01:11:06 -0800, Kris Kennaway wrote:
=20
Another problem (noticed by tjr) is that
[EMAIL PROTECTED] writes:
BTW, note that new formulae also used in the kernel (by BSD developers)
and taken from there - libkern/random.c - so all you say is true there
too.
It should be nuked from the kernel, and arc4random() used instead.
I agree. If no-one objects, I'll do this?
M
--
On Sun, Feb 02, 2003 at 01:11:06 -0800, Kris Kennaway wrote:
Another problem (noticed by tjr) is that once the sequence hits '0' it
jumps to INT_MAX and stays there forever. For example, seeding with
srand(0) produces nothing but INT_MAX from rand().
It looks like a lot more validation of
Thus spake Andrey A. Chernov [EMAIL PROTECTED]:
Yes, first value correlation is there, but old formulae have even worse
effect The random sequences do not vary much with the seed, as source
file comments and whole discussion about old RNG bad effects shown. I.e.
for different time+PID
On Sun, Feb 02, 2003 at 03:48:17 -0800, David Schultz wrote:
Specifically, rand() isn't very interesting in the lower-order
bits, and it spectacularly fails nearly all of Marsaglia's
It seems that you speak about old formulae, we use new one (which
intended to fix low-ordered bits), see our
On Sun, Feb 02, 2003 at 13:26:21 +0300, Andrey A. Chernov wrote:
Workaround I find so far is something like that
#define MASK 123459876
I found nothing better. Here is fix for 0 problem I plan to commit:
--- stdlib/rand.c.old Sat Jan 4 20:39:19 2003
+++ stdlib/rand.c Sun Feb 2
On Sun, 2 Feb 2003, Andrey A. Chernov wrote:
On Sun, Feb 02, 2003 at 13:26:21 +0300, Andrey A. Chernov wrote:
Workaround I find so far is something like that
#define MASK 123459876
I found nothing better. Here is fix for 0 problem I plan to commit:
I think it's worthwhile to wait till
On Sun, Feb 02, 2003 at 04:38:53 -0800, Doug Barton wrote:
I think it's worthwhile to wait till we get a chance to try arc4random().
This is libc's rand/random, it can't be fixed with arc4random() as
designed.
Also, have you run the code you're proposing through the tests in the post
that
On Sun, Feb 02, 2003 at 03:30:35PM +0300, Andrey A. Chernov wrote:
On Sun, Feb 02, 2003 at 13:26:21 +0300, Andrey A. Chernov wrote:
Workaround I find so far is something like that
#define MASK 123459876
I found nothing better. Here is fix for 0 problem I plan to commit:
---
On Mon, Feb 03, 2003 at 00:17:35 +1100, Tim Robbins wrote:
I believe that this change just moves the bad seed to 123459876; after
calling srand() with that seed, each call to rand() returns 0.
Yes. Nothing better is possible for this formulae and this is documented
in algorithm, some value
On Sun, Feb 02, 2003 at 16:42:25 +0300, Andrey A. Chernov wrote:
On Mon, Feb 03, 2003 at 00:17:35 +1100, Tim Robbins wrote:
I believe that this change just moves the bad seed to 123459876; after
calling srand() with that seed, each call to rand() returns 0.
Yes. Nothing better is
On Sun, Feb 02, 2003 at 17:02:23 +0300, Andrey A. Chernov wrote:
I'll produce and send it a bit later.
Here it is.
--- stdlib/rand.c.old Sat Jan 4 20:39:19 2003
+++ stdlib/rand.c Sun Feb 2 17:06:08 2003
@@ -72,10 +72,13 @@
*/
long hi, lo, x;
+ /* Can't be
So far, this is final variant for 0 problem fixing ready for committing.
Any objections?
--- stdlib/rand.c.old Sat Jan 4 20:39:19 2003
+++ stdlib/rand.c Sun Feb 2 17:34:34 2003
@@ -72,10 +72,13 @@
*/
long hi, lo, x;
+ /* Can't be initialized with 0, so use another
David Schultz [EMAIL PROTECTED] writes:
[2] http://stat.fsu.edu/~geo/diehard.html (you need ports/lang/f2c)
There's a native C version on Marsaglia's random number CD:
http://stat.fsu.edu/pub/diehard/cdrom/die.c/
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to
Jeroen C. van Gelderen writes:
Wouldn't it be a good idea to change the name at the same time? Or
should it be retained for compatibility reasons with other BSDs?
Currently the name needlessly exposes implementation detail. Callers
expect good, cheap, non-blocking randomness but don't give
On Sun, Feb 02, 2003 at 15:32:32 +, Mark Murray wrote:
Jeroen C. van Gelderen writes:
Wouldn't it be a good idea to change the name at the same time? Or
should it be retained for compatibility reasons with other BSDs?
Currently the name needlessly exposes implementation detail.
Andrey A. Chernov writes:
On Sun, Feb 02, 2003 at 04:38:53 -0800, Doug Barton wrote:
I think it's worthwhile to wait till we get a chance to try arc4random().
This is libc's rand/random, it can't be fixed with arc4random() as
designed.
Why not? Arc4 is a) deterministic and b) good for
Andrey A. Chernov writes:
On Mon, Feb 03, 2003 at 00:17:35 +1100, Tim Robbins wrote:
I believe that this change just moves the bad seed to 123459876; after
calling srand() with that seed, each call to rand() returns 0.
Yes. Nothing better is possible for this formulae and this is
Andrey A. Chernov writes:
Objections?
We can't, simple because sequence must be repeated for the same seed
across the calls.
RC4 is repeatable.
M
--
Mark Murray
iumop ap!sdn w,I idlaH
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the
On Sun, Feb 02, 2003 at 17:30:48 +, Mark Murray wrote:
Why not? Arc4 is a) deterministic and b) good for all bits.
If you mean arc4random() function - not, because it use true randomness,
if you mean RC4 algorithm, probably yes, but we should compare its
distribution with our current
On Sun, Feb 02, 2003 at 17:34:19 +, Mark Murray wrote:
Andrey A. Chernov writes:
Objections?
We can't, simple because sequence must be repeated for the same seed
across the calls.
RC4 is repeatable.
It seems we mean different things saying arc4random(), see my answer in
the
On Sun, Feb 02, 2003 at 21:20:09 +0300, Andrey A. Chernov wrote:
On Sun, Feb 02, 2003 at 17:30:48 +, Mark Murray wrote:
Why not? Arc4 is a) deterministic and b) good for all bits.
If you mean arc4random() function - not, because it use true randomness,
if you mean RC4 algorithm,
In message [EMAIL PROTECTED], Andrey A. Chernov writes:
On Sun, Feb 02, 2003 at 17:30:48 +, Mark Murray wrote:
Why not? Arc4 is a) deterministic and b) good for all bits.
If you mean arc4random() function - not, because it use true randomness,
if you mean RC4 algorithm, probably yes, but
On Sun, Feb 02, 2003 at 19:32:50 +0100, [EMAIL PROTECTED] wrote:
Anyway, last time we discussed this, I think we stuck with the rand()
we had because we feared that people were using it's repeatable well
documented sequence of random numbers in regression testing.
As documented, it must be
Andrey A. Chernov writes:
On Sun, Feb 02, 2003 at 17:30:48 +, Mark Murray wrote:
Why not? Arc4 is a) deterministic and b) good for all bits.
If you mean arc4random() function - not, because it use true randomness,
if you mean RC4 algorithm, probably yes, but we should compare its
In message [EMAIL PROTECTED], Andrey A. Chernov writes:
On Sun, Feb 02, 2003 at 19:32:50 +0100, [EMAIL PROTECTED] wrote:
Anyway, last time we discussed this, I think we stuck with the rand()
we had because we feared that people were using it's repeatable well
documented sequence of random
In message [EMAIL PROTECTED], Mark Murray wr
ites:
We have most of this, and RC4 can deliver. RC4's licence is
fine. Call it ArCFour and there is no problem. The code is
small, fast and repeatable, and meets conditions 1-4 above.
There are some concerns about RC4's strength and predictability.
Good point. We can re-implement random() internally with arc4rand().
Objections?
Guys, please realize that random() is also used in generating
simulation inputs (or timing or whatever). If you go change
the underlying algorithm or its parameters one can't generate
the same sequence from the
On Sun, Feb 02, 2003 at 19:43:44 +0100, [EMAIL PROTECTED] wrote:
Please surf the mail-archives to find the discussion, it contained
a lot of good arguments from both sides, arguments which should
be thought about before changing rand().
I remember well that we decide to allow it be changed
On Sun, Feb 02, 2003 at 19:47:12 +0100, [EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED], Mark Murray wr
ites:
We have most of this, and RC4 can deliver. RC4's licence is
fine. Call it ArCFour and there is no problem. The code is
small, fast and repeatable, and meets conditions 1-4
[EMAIL PROTECTED] writes:
In message [EMAIL PROTECTED], Mark Murray
wr
ites:
We have most of this, and RC4 can deliver. RC4's licence is
fine. Call it ArCFour and there is no problem. The code is
small, fast and repeatable, and meets conditions 1-4 above.
There are some concerns about
As I said, I don't know how big a concern this is. But last time
it was enough of a concern to make us keep rand() as it was.
[I know you are talking about rand() but Mark Murray's
earlier email about wanting to re-implement random() really
concerned me so I want to make sure my point gets
Bakul Shah writes:
Good point. We can re-implement random() internally with arc4rand().
Objections?
Guys, please realize that random() is also used in generating
simulation inputs (or timing or whatever). If you go change
the underlying algorithm or its parameters one can't generate
Bakul Shah writes:
Not changing random() was of real concern to me when I was
doing chip simulations. ASIC design verification folks won't
be happy if the rug is pulled out from under them. In
general crypto and simulation needs are different and I don't
trust the crypto guys to look out
On Sun, Feb 02, 2003 at 07:08:47PM +, Mark Murray wrote:
RC4 is _utterly_ repeatable, given a particular seed/key.
I presume it also produces reasonably uniform output for most
seeds too.
The old 16 bit rand() was broken enough that it didn't matter
much (read: _I_ don't care) if its
On Sunday 02 February 2003 6:48 pm, Bakul Shah wrote:
Guys, please realize that random() is also used in generating
simulation inputs (or timing or whatever). If you go change
the underlying algorithm or its parameters one can't generate
the same sequence from the same seed when repeating a
David Malone writes:
On Sun, Feb 02, 2003 at 07:08:47PM +, Mark Murray wrote:
RC4 is _utterly_ repeatable, given a particular seed/key.
I presume it also produces reasonably uniform output for most
seeds too.
Yes. Modulo the requirement to burn a bit of output after a
reseed.
The
RC4 is _utterly_ repeatable, given a particular seed/key.
May be but it is not the same as the current random(). Also,
I know you will want to change it the next time some one
points out a problem with RC4.
Yes. And it breaks, and we have a complainant.
So create a new function! Or use a
I presume it also produces reasonably uniform output for most
seeds too.
Yes. Modulo the requirement to burn a bit of output after a
reseed.
I guess the crypto guys would have junked it otherwise ;-)
I thought the complaint was about rand, not random?
Erm, yes. Similar difference
Maybe I missed something, but why cannot you just rip random() from libc,
rename it to bakul_shah_random() and use that in your testing code? Then you
are safe from any changes to random(), and indeed have a portable RNG if your
host OS changes.
Yes, *I* can do it but I don't work at every
On Sunday 02 February 2003 8:06 pm, Bakul Shah wrote:
Maybe I missed something, but why cannot you just rip random() from libc,
rename it to bakul_shah_random() and use that in your testing code? Then
you are safe from any changes to random(), and indeed have a portable RNG
if your host
Bakul Shah writes:
RC4 is _utterly_ repeatable, given a particular seed/key.
May be but it is not the same as the current random(). Also,
I know you will want to change it the next time some one
points out a problem with RC4.
Yes. This is called fixing bugs. We (OS maintainers) reserve
Bakul Shah writes:
Yes, *I* can do it but I don't work at every place they do
simulation! If in the extreme you are suggesting that a
portable application shouldn't rely on any OS features, you
are of course right but that kind of makes mockery of any
claims of compatibility. The point of
On Sun, Feb 02, 2003 at 20:05:29 +, David Malone wrote:
I presume it also produces reasonably uniform output for most
seeds too.
Yes. Modulo the requirement to burn a bit of output after a
reseed.
I guess the crypto guys would have junked it otherwise ;-)
Notice that it will
a restriction on the OS. If FreeBSD makes random2() using RC4 to avoid
changing rand() or random(), will people then start relying on random2()'s
behaviour, and when someone finds a problem in RC4, then the next will be
random3()?
What I am suggesting is to leave random() as it is and
On Sun, Feb 02, 2003 at 12:39:50 -0800, Bakul Shah wrote:
Note that it is rand() that is broken, not random() as can be
seen by modifying Kris Kennaways' test so I don't see why
Mark Murray was talking about changing it in the first place.
About correlation bug: it is srand() which is
On Sun, Feb 02, 2003 at 12:06:56PM -0800, Bakul Shah wrote:
Maybe I missed something, but why cannot you just rip random() from libc,
rename it to bakul_shah_random() and use that in your testing code? Then you
are safe from any changes to random(), and indeed have a portable RNG if your
On Sun, Feb 02, 2003 at 11:55:25AM -0800, Bakul Shah wrote:
RC4 is _utterly_ repeatable, given a particular seed/key.
May be but it is not the same as the current random(). Also,
I know you will want to change it the next time some one
points out a problem with RC4.
Since you keep talking
Would you prefer that we defined random() as
int
random(void)
{
static int retval = 0;
return retval++;
}
No because that would be a change from the exisiting random()
behavior :-)
As I indicated in my earlier email random() is not broken,
srand() is (as corrected by
Since you keep talking about random(), I must conclude you're
knee-jerking, since we're not discussing that function. Please stay
on-topic :-)
Read through the thread. In particular see Mark's message
[EMAIL PROTECTED] where he
says
Good point. We can re-implement random() internally
Bakul Shah writes:
Note that it is rand() that is broken, not random() as can be
seen by modifying Kris Kennaways' test so I don't see why
Mark Murray was talking about changing it in the first place.
rand(3) says:
STANDARDS
The rand() and srand() functions conform to ISO/IEC 9899:1990
On Sun, Feb 02, 2003 at 12:57:45PM -0800, Bakul Shah wrote:
Since you keep talking about random(), I must conclude you're
knee-jerking, since we're not discussing that function. Please stay
on-topic :-)
Read through the thread. In particular see Mark's message
[EMAIL PROTECTED] where
1 - 100 of 148 matches
Mail list logo
