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
> > >
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 w
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, bu
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: 55
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 se
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 objecti
"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
"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 ge
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:
>
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
"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 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.
--
Andr
"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: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 gener
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 (
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):
> > http://www.cs.utsa.edu/~wa
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):
> > http
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 sug
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 t
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
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 en
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
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 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 sugges
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
> > th
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
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 t
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 stuf
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) p
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
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
> nu
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 l
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 pr
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 PRNG
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 o
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
"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 t
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 fo
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 Unsu
"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 commo
> > > 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
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 Hellman
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 f
* 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 Fr
> > 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 4.{2,
Steve Kargl wrote:
> On Sun, Feb 02, 2003 at 04:37:07PM -0800, Terry Lambert wrote:
> > I can fire up my HP/UX and SunOS 4.1.3-U1 boxes too, if you need
> > those, but I'm pretty sure the reason you got a different answer
> > for newer Solaris was because it uses the SVR4 code, instead.
>
> That's
Edward Brocklesby wrote:
> On Monday 03 February 2003 12:20 am, Terry Lambert wrote:
> > Edward Brocklesby wrote:
> > > Where was it indicated that random() wouldn't change?
> >
> > Right there in the boot message, and again when you logged in,
> > where the system indicated to you that it was a BS
Don wrote:
> > > It isn't a question of the API. It's a question of expected function
> > > output.
> >
> > Then it's applicable not only to binary packages as Terry states, but any
> > source that uses rand().
>
> I think Terry mentioned binary packages simply because it is harder to fix
> them t
On Monday 03 February 2003 12:41 am, Don wrote:
> I think Terry mentioned binary packages simply because it is harder to fix
> them than something available as source but I could be mistaken.
Possibly -- if we're looking at this from the point of view of the user of
said binary package, rather th
Terry Lambert wrote:
> > Last 10 digits.
> >
> > FreeBSD Redhat SunOS
> 386BSD 0.1+
> patchkitTRU64
Crap.
Ignore these numbers. I replaced the libc implementation on both
these machines, and forgot I had done it. When I put the code
back to what it was, they give the Solar
On Sun, Feb 02, 2003 at 04:37:07PM -0800, Terry Lambert wrote:
>
> I can fire up my HP/UX and SunOS 4.1.3-U1 boxes too, if you need
> those, but I'm pretty sure the reason you got a different answer
> for newer Solaris was because it uses the SVR4 code, instead.
>
That's the whole point! You sh
Mark Murray wrote:
> > That's why randomness tests + mathematician to interpretate their results
> > are needed to compare what we have now in random(3) with RC4. Easy and
> > understandable code not always mean better results. We can't switch
> > algorithms blindly, i.e. when their comparative qua
On Monday 03 February 2003 12:20 am, Terry Lambert wrote:
> Edward Brocklesby wrote:
> > Where was it indicated that random() wouldn't change?
>
> Right there in the boot message, and again when you logged in,
> where the system indicated to you that it was a BSD system;
Sorry, I can't quite work
> > It isn't a question of the API. It's a question of expected function
> > output.
>
> Then it's applicable not only to binary packages as Terry states, but any
> source that uses rand().
I think Terry mentioned binary packages simply because it is harder to fix
them than something available as s
Steve Kargl wrote:
> I was going to stay out of this, but
>
> #include
> #include
> int main(void) {
> int i;
> long x;
> x = 100L;
> srandom(x);
> for (i = 0; i < 1010; i++) {
> x = random();
> printf("%ld\n", x);
> }
> return 0;
> }
>
> Last 10 digits.
>
> FreeBSD
Thus spake Andrey A. Chernov <[EMAIL PROTECTED]>:
> 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
>
On Monday 03 February 2003 12:18 am, Don wrote:
> It isn't a question of the API. It's a question of expected function
> output.
Then it's applicable not only to binary packages as Terry states, but any
source that uses rand().
> I run FreeBSD and not Linux because of the stability and predict
Doug Barton <[EMAIL PROTECTED]> wrote:
>
>I can think of one significant benefit... I had noticed that my perl
>script to pick random windowmaker themes (which uses rand()) seemed to be
>picking the same themes over and over again.
That's a bug in perl's compile-time configuration. It can be told
Doug Barton wrote:
> I can think of one significant benefit... I had noticed that my perl
> script to pick random windowmaker themes (which uses rand()) seemed to be
> picking the same themes over and over again. Now I know why. :) I had to
> create a "last seen" list to artificially increase the "
Edward Brocklesby wrote:
> On Sunday 02 February 2003 8:39 pm, Bakul Shah wrote:
> > What I am suggesting is to leave random() as it is and
> > guarantee its behavior won't change and add cryto_random() or
> > whatever, and indicate it *may* change.
>
> Where was it indicated that random() wouldn'
> > Binary packages from third party software vendors.
>
> What about them? They either,
> a) link to a static libc, and use its rand() always; or
> b) link to a shared libc, and use its rand(), as the binary API hasn't
> changed; or
It isn't a question of the API. It's a question of expected funct
> Interesting The SunOS output exactly matches random(3)
> behavior from 4.3BSD! In fact random() remained the same for
> 4.3BSD-Reno, -Tahoe, 4.4BSD-Alpha and Net2.
>
> 4.2BSD random() behavior is different from all of the above.
> There was real bug-fix between 4.2BSD and 4.3BSD.
>
> I do
Mark Murray wrote:
> Bakul Shah writes:
> > random(3) also provides an initstate() call which presumably
> > allows you to change the amount of randomnes. So here is
> > another suggestion: why not fold your algorithm change in
> > that function? For example,
> >
> > initstate(seed, "RC4", 3)
On Sun, Feb 02, 2003 at 04:02:27PM -0800, 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
On Sunday 02 February 2003 11:59 pm, Terry Lambert wrote:
> Edward Brocklesby 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
Mark Murray <[EMAIL PROTECTED]> wrote:
>
>3) int random(void) which returns a number statistically
> random in all bits.
>
>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
* 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 aggrees w
Edward Brocklesby wrote:
> 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
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.
I tried that, and it didn't repeat the sequence I got when I
previously used "rand()"... 8-) 8-).
-- Terry
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. Callers
> > expect good, cheap, non-
[From address modified because I don't want every message in this
thread to end up in my personal mailbox. I'll read them in the
list, thank you very much.]
On Sun, Feb 02, 2003 at 09:23:43PM +, Mark Murray wrote:
> Bakul Shah writes:
> > > Since you keep talking about random(), I must conclu
> Last 10 digits.
>
> FreeBSD Redhat SunOS
> 660787754660787754645318364
> 3275486913275486911583150371
> 2009993994 2009993994 715222008
> 1653966416 1653966416 1349166998
> 1074113008 1074113008 566227131
> 2142626740 2142626740 1382825076
> 15177758
On Sun, Feb 02, 2003 at 02:37:25PM -0800, Steve Kargl wrote:
> FreeBSD Redhat SunOS
> 660787754660787754645318364
FWIW - AIX aggrees with Solaris.
David.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
"Andrey A. Chernov" writes:
> On Sun, Feb 02, 2003 at 22:35:54 +, Mark Murray wrote:
> >
> > I stand (somewhat) corrected. The random() code is _nasty_ complexity-wise.
> > Its not obvious how it works.
> >
> > RC4 is 10-20 lines and clean with no magic numbers.
>
> That's why randomness tes
Thus spake Bakul Shah <[EMAIL PROTECTED]>:
> > 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
On Sun, Feb 02, 2003 at 22:35:54 +, Mark Murray wrote:
>
> I stand (somewhat) corrected. The random() code is _nasty_ complexity-wise.
> Its not obvious how it works.
>
> RC4 is 10-20 lines and clean with no magic numbers.
That's why randomness tests + mathematician to interpretate their res
"Andrey A. Chernov" writes:
> On Sun, Feb 02, 2003 at 22:19:33 +, Mark Murray wrote:
>
> > > 1) Implementing random(3) with RC4 is not needed, its algorithm is
> > > already equal or better.
> >
> > Rubbish. :-) RC4's internal state is 256 bytes. In theory, its
> > cycle-of-repetition is 2^(
On Sun, Feb 02, 2003 at 01:59:25PM -0800, Bakul Shah wrote:
>
> AFAIK all random(3) implementations in various versions of
> Unix come from Earl's original 4.2BSD implementation so in my
> view the _expected_ behavior is to see the _exact_ same
> sequence starting from a given seed. This function
On Sun, Feb 02, 2003 at 22:19:33 +, Mark Murray wrote:
> > 1) Implementing random(3) with RC4 is not needed, its algorithm is
> > already equal or better.
>
> Rubbish. :-) RC4's internal state is 256 bytes. In theory, its
> cycle-of-repetition is 2^(8*256) bits.
This is comparable with rand
On Sun, Feb 02, 2003 at 14:21:02 -0800, Kris Kennaway wrote:
>
> 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
"Andrey A. Chernov" writes:
> On Sun, Feb 02, 2003 at 21:23:43 +, Mark Murray wrote:
> >
> > That was random(9). KERNEL random().
>
> KERNEL random() can be easily implemented (better - replaced) with
> arc4random(), there is no objections. But...
>
> 1) Implementing random(3) with RC4 is no
On Mon, Feb 03, 2003 at 12:55:40AM +0300, Andrey A. Chernov wrote:
> On Sun, Feb 02, 2003 at 13:06:08 -0800, Kris Kennaway wrote:
> > On Sun, Feb 02, 2003 at 06:10:49PM +0300, Andrey A. Chernov wrote:
> > > So far, this is final variant for 0 problem fixing ready for committing.
> > > Any objectio
Bakul Shah writes:
> > No. Evil interface change. #ifdef hell while programs try to
> > figure out OS differences.
>
> How so? This or a similar change is upward compatible in
> that the existing behavior is left unchanged and it gives you
> a way to replace the algorithm.
It requies that progra
On Sun, Feb 02, 2003 at 21:23:43 +, Mark Murray wrote:
>
> That was random(9). KERNEL random().
KERNEL random() can be easily implemented (better - replaced) with
arc4random(), there is no objections. But...
1) Implementing random(3) with RC4 is not needed, its algorithm is
already equal or
> > another suggestion: why not fold your algorithm change in
> > that function? For example,
> >
> > initstate(seed, "RC4", 3);
> >
> > changes the algorithm to RC4. Yes, this is a change in the
> > interface but one I am sure most people can live with.
>
> No. Evil interface change. #ifd
On Sun, Feb 02, 2003 at 13:06:08 -0800, Kris Kennaway wrote:
> On Sun, Feb 02, 2003 at 06:10:49PM +0300, Andrey A. Chernov wrote:
> > So far, this is final variant for 0 problem fixing ready for committing.
> > Any objections?
>
> What tests have you run on this code to ensure it doesn't still ha
On Sun, Feb 02, 2003 at 13:12:55 -0800, Doug Barton wrote:
>
> If I had to guess, I'd say that you're eager to fix the mistake you made,
> and I suppose that's commendable. However, it's been broken for two years,
> it can wait another couple days for a more thorough fix.
If you talk about 0 prob
Bakul Shah writes:
> > 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. W
On Sun, 2 Feb 2003, Bakul Shah wrote:
> Yes, *I* can do it but I don't work at every place they do
> simulation!
Well the code is still going to be available in cvs. It's not like we're
going to magically make it disappear. :)
> If in the extreme you are suggesting that a
> portable application
On Sunday 02 February 2003 8:39 pm, Bakul Shah wrote:
> What I am suggesting is to leave random() as it is and
> guarantee its behavior won't change and add cryto_random() or
> whatever, and indicate it *may* change.
Where was it indicated that random() wouldn't change?
> Note that it is rand() t
On Sun, 2 Feb 2003, Andrey A. Chernov wrote:
> So far, this is final variant for 0 problem fixing ready for committing.
> Any objections?
Several people, including myself have asked for A) Enough discussion to
reach a consensus, and B) Thorough testing of the agreed upon solution.
You have allowe
Bakul Shah writes:
> random(3) also provides an initstate() call which presumably
> allows you to change the amount of randomnes. So here is
> another suggestion: why not fold your algorithm change in
> that function? For example,
>
> initstate(seed, "RC4", 3);
>
> changes the algorithm to
On Sun, Feb 02, 2003 at 06:10:49PM +0300, Andrey A. Chernov wrote:
> So far, this is final variant for 0 problem fixing ready for committing.
> Any objections?
What tests have you run on this code to ensure it doesn't still have
strange problems?
Kris
msg51583/pgp0.pgp
Description: PGP si
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
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
> 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() internall
> 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
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 ta
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 y
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 bro
1 - 100 of 152 matches
Mail list logo
