From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 29 07:13:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A0523EC for ; Fri, 29 Aug 2014 07:13:04 +0000 (UTC) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D54B1F35 for ; Fri, 29 Aug 2014 07:13:04 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id bj1so5833060pad.32 for ; Fri, 29 Aug 2014 00:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UFSrSZaFl+LNoM+gycuXrrjYeyJvQytDHdEJBQF1z4Y=; b=LziAczXhxjxpQ/NHMWs9FYssYof9GCyS/Sr1ou/Z/xHlAWmulmX3VcNFmlhFr7O3HX son810rXdPVTlkMGOkjE5PKQkBJ/djDIFXIUMBSSF3Mo9cE7zGCkG940N4IsXt/LQ7jU xbsSfWsUMALKX3fmid+iCPl9WkRsRt2qm3mo0YLNnHyzjk/ZF/mKaH5IJqm8LqrLEDpO zT4UpHwFT3nFWJBTZeO5Sn4XangTqzfuaQwlFmUZvaffGXKNPfKgVV1ijbtRJd6J8Oho /pRqJrispjQqVIN5TNYv2iNv1iUfN7aDyaCpB6ZTD4GvF78luOnbrOSYxqnhXghsTKGz 3kaQ== X-Received: by 10.68.65.36 with SMTP id u4mr12801869pbs.127.1409296383558; Fri, 29 Aug 2014 00:13:03 -0700 (PDT) Received: from [10.240.140.110] ([123.58.191.67]) by mx.google.com with ESMTPSA id xr10sm20763923pab.35.2014.08.29.00.13.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Aug 2014 00:13:03 -0700 (PDT) Content-Type: text/plain; charset="utf8"; Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: On changing rand(3) to random(3) in awk(1) X-Pgp-Agent: GPGMail (null) From: Chenguang Li In-Reply-To: <53FF574E.1090108@gmail.com> Date: Fri, 29 Aug 2014 15:12:44 +0800 Content-Transfer-Encoding: 8bit Message-Id: <78248D53-D8B6-4135-B900-74E0047F92F1@gmail.com> References: <53FEFBB8.5040305@gmail.com> <20140828131526.GA2385@straylight.m.ringlet.net> <5C40F611-22EB-49E4-8925-37922E771C0F@gmail.com> <53FF574E.1090108@gmail.com> To: Vitaly Magerya X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 07:13:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Vitaly Magerya wrote: > On 08/28/14 16:28, Chenguang Li wrote: >> I am using RANDOM_MAX here to maintain the original code structure. >> I've updated my patch, please check the gist. Thanks! >> >> jmp_buf env; >> extern int pairstack[]; >> @@ -1522,7 +1522,7 @@ >> break; >> case FRAND: >> /* in principle, rand() returns something in 0..RAND_MAX */ >> - u = (Awkfloat) (rand() % RAND_MAX) / RAND_MAX; >> + u = (Awkfloat) (random() % RANDOM_MAX) / RANDOM_MAX; >> break; >> case FSRAND: >> if (isrec(x)) /* no argument provided */ > > OK, so this part is wrong (and it is wrong in the original sources > too): this construction generates 0.0 twice as often as it generates > other numbers -- both when random() returns 0 and when it returns > RANDOM_MAX. The correct construction is this: Yes, I've noticed there's a fairness problem, 0 comes out more often. Since the original code is buggy too, do we need to be compatible with it? >> case FRAND: >> - /* in principle, rand() returns something in 0..RAND_MAX */ >> - u = (Awkfloat) (rand() % RAND_MAX) / RAND_MAX; >> + /* random() returns values in [0, RANDOM_MAX] */ >> + u = (Awkfloat) random() / (RANDOM_MAX + 1ul); >> break; > > Note that the "ul" part in "1ul" is vitally important: otherwise there > will be an overflow on systems where long is 32 bit wide. Alternatively > "1.0" can be used here instead. > > (Because this overflow may not be obvious in a casual reading, I'm not > a fan of defining RANDOM_MAX separately; I personally would insert the > actual number here directly). Thanks for pointing that out, I've modified the gist as your suggestion. Chenguang Li -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUACfzAAoJELG4cS+11lRhIFgQAII3b12r1JO+KPbnXfEdrsoA SFaRiG/Z6a8gQBpqTdUA4te9wT+FxQO081bipUv2po7Ys4MZOPkSJ8jh0jiZ02NX Vw95A+8TfUS5CWq78eqiSgP/x9UxomJ20qM5eUlhslRUX/8Lr4tpVQ3gGuCK0i5n bq3TgbJiNKaHPwSniVCDv2saS3lUGZp1QWxMK4ecwrmXoMlkNRpBygb2zRep2Q9p L9ccIQXmDZnZV5A/udIieGbvz5Gfk1utbOTwii41d+1j+zeWtkBlaMFDoWtNhqwp 31EIVQonSPTqStDAOptsixfI5O7G0mfa3nk1eDj+dUABg6qQbPtjWlG9uZL3JjZb A1ESdzlUSyxoOR2zoEkCgadAkMrbaqA2ziZvPB0o/ClwI99j3htUY+a9NJJmk43y qDQ0rBaQhj5TajUxsRir46sV70hpITBQP6EB4E18zWpT+GtgUkbPpW3CeKNcCuDk omTL6XZoS2jXyd62m9woDN3txddvU3XBJxiSL0Mo0hpUnwgg6GCtceAVkQvX6mck bCBZDPYzsIPMY30esJcL+NkLViwbVufthP/E8pWRU4Jn1a4bCrEA+WBkfTRhI53K Ph9zMVmZyD/SBwzbgi5eHYdAjTLjOAWyYQpPJ4vRQOe4iX9WNOPF36DjbnAUMLl/ f5sCba2r0hxdjksFQsDF =FBZK -----END PGP SIGNATURE-----