From owner-freebsd-hackers Wed Feb 19 0:19:31 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D56D37B401 for ; Wed, 19 Feb 2003 00:19:30 -0800 (PST) Received: from mail.deltanet.com (mail.deltanet.com [216.237.144.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4032543FAF for ; Wed, 19 Feb 2003 00:19:29 -0800 (PST) (envelope-from pherman@frenchfries.net) Received: from mammoth.eat.frenchfries.net (da001d0107.lax-ca.osd.concentric.net [66.239.48.107]) by mail.deltanet.com (8.11.6/8.11.6) with ESMTP id h1J8I2Q15950 for ; Wed, 19 Feb 2003 00:18:06 -0800 Received: by mammoth.eat.frenchfries.net (Postfix, from userid 1000) id 30B154B4B; Wed, 19 Feb 2003 00:16:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mammoth.eat.frenchfries.net (Postfix) with ESMTP id BFEFE4B45; Wed, 19 Feb 2003 00:16:57 -0800 (PST) Date: Wed, 19 Feb 2003 00:16:57 -0800 (PST) From: Paul Herman X-X-Sender: pherman@mammoth.eat.frenchfries.net To: Peter Jeremy Cc: FreeBSD Hackers Subject: Re: arc4random() range In-Reply-To: <20030219063646.GB62020@cirb503493.alcatel.com.au> Message-ID: <20030218232210.T240-100000@mammoth.eat.frenchfries.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 19 Feb 2003, Peter Jeremy wrote: > On Tue, Feb 18, 2003 at 06:22:37PM -0800, Paul Herman wrote: > > > > [...range of arc4random() is twice that of random()...] > > I see this as a major advantage of arc4random() I see this as an advantage, too. It's also produces random numbers with a very long period. It's also not too slow. But that's not what put the bee in my bonnet. The disadvantage is that it doesn't behave like random()/rand(), like I mistakingly assumed despite reading the manpage. Background: I probably spent an hour trying to figure out why my monte carlo simulations (dealing with concordance of ranking tables) were skewed until I narrowed it down to arc4random() producing random numbers twice as big as random(). So, I was first going to post to -doc about the lack of this fact in the manpage to possibly spare others from a similar tribulation, but it occurred to me to ask on -hackers what people thought about this break from "tradition" first. Unfortunately, this behavior is inconsistent with random(), perhaps for good reason, but perhaps indeed the strongest argument above any other for *not* changing arc4random() to a drop-in replacement for random()/rand() is legacy: it's already been this way for quite some time now and some code may depend on this behavior now. If no one disagrees, I suggest an addition to the manpage along the lines of: arc4random() returns random numbers in the range of 0 to (2**32)-1, and therefore has twice the range of RAND_MAX. and if we are feeling really generous: EXAMPLES The following produces a drop-in replacement for the traditional random() and rand() functions using arc4random(): #define arc4random31() (arc4random() & 0x7FFFFFFF) -Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message