Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113933 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 15256 invoked from network); 2 Apr 2021 22:51:50 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 2 Apr 2021 22:51:50 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 26FC8180507 for ; Fri, 2 Apr 2021 15:49:58 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, SPF_HELO_PASS,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 2 Apr 2021 15:49:57 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 84F4115C5 for ; Fri, 2 Apr 2021 18:49:55 -0400 (EDT) Received: from imap8 ([10.202.2.58]) by compute4.internal (MEProxy); Fri, 02 Apr 2021 18:49:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=mNA/2k y2qrYa3XYkT23a4MgvpULWq+AUTEfxKnhGTno=; b=CmrE+uDbCvoVrgVh25Aa0w hoD7rjBGmWCLZ+dLdXLBbdAZG1jY83iV1T6OoYEA665xXGP4mG15Kg3Hp1q9ixhH xLRKBLYcA0+wPvHBldjjjjScS3Q9N0eY5mIvFdXkBOja0Y/QbDTiuuNNQRvIe+9S CSP0+6yjkArpkSNwU/sLV2w2V6gfgSv+gbqL3tKJ1ogUOUGglGwMqKMpvzhi7h6N S3Uc0+RuSefwh07UuATOgJDd3zNNbx9dWfAqIlbGigAtF3froTwM5Ss5+U7wkVr4 tf9/JxLCN+hmm4DIjPqv5PUyS3WYt9Qxn30kpluOKfDK5uLfSHMYZ6fbPyrgl+tQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudeijedgudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdfnrghr rhihucfirghrfhhivghlugdfuceolhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtoh hmqeenucggtffrrghtthgvrhhnpeeglefgkeduiedvvdetffeujefftdfhjeeiveehgfff keduveektddvledvvdfffeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehlrghrrhihsehgrghrfhhivghlughtvggthhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D0CD73A093B; Fri, 2 Apr 2021 18:49:54 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-273-g8500d2492d-fm-20210323.002-g8500d249 Mime-Version: 1.0 Message-ID: <981a25de-e61c-4703-9be1-fd03b0409245@www.fastmail.com> In-Reply-To: References: Date: Fri, 02 Apr 2021 17:49:32 -0500 To: "php internals" Content-Type: text/plain Subject: Re: [PHP-DEV] [VOTE] Object scoped RNG implementation From: larry@garfieldtech.com ("Larry Garfield") On Fri, Apr 2, 2021, at 4:56 PM, Kamil Tekiela wrote: > Hi Go Kudo, > > First, let me say that I believe we need such implementation in PHP and I > would like to see object scoped RNG as part of the standard. However, I > have voted no for a number of reasons. Let me list them from the > perspective of a noob PHP user. > > - I really do not understand why we are introducing new functions. Can't > the classes implement the necessary methods to get integers, doubles, and > string of bytes? As a new user I would be completely overwhelmed by all > these functions: rand(), mt_rand(), rng_int(), rng_next(), rng_next64(). > Which one should I use? What is the difference between rng_next() > and rng_next64? > - As soon as I left the RFC page I forgot what the new classes were called. > I still can't tell from memory what's their name. I understand what they > mean, but they are definitely not friendly names. > - What's the difference between MT19937 and XorShift128Plus? They are > different algorithms but which one should I pick? I tested the > implementation locally and I see no difference in performance. > - I am not a fan of adding a new optional parameter to shuffle() and > friends. I'd prefer to have a method in the class that I can pass an array > to. > - What is the default seed? Do I have to provide a seed each time? Why > can't the seed be done automatically? > - Signed? Unsigned? As far as I know, PHP doesn't have unsigned integers. > What's the real-life purpose of this flag? > - I don't see any use in supporting userland implementations. Why can't > they create separate libraries? I don't know about performance, but if > someone wants to have custom RNG then I don't think they worry about > performance. > - When using the functions the performance was 50% worse than when calling > ->next() directly. Is this right or is the implementation going to be > optimized further? The fastest way to get a random number seems to be > mt_rand() based on my tests. > > I would rather like to see a single class called RNG/Random that implements > RNG/RandomInterface. The constructor of the class would take 2 arguments. > The first is the algorithm with a default either MT or XORShift. The second > is an optional seed. If no seed is provided then the seed is generated > automatically like in mt_srand(). The class would then implement methods > like: nextInt(), nextDouble(), nextBytes(), arrayShuffle(), > stringShuffle(), randomArrayKeys(). I would keep the standard functions as > they are. Let them use MT by default. We could even deprecate them in > future if this takes off. > > This would make it painfully obvious what the class does and how to use it. > No more procedural code. I would also make the class final so that you > can't inherit from it, but that is highly opinion-based. > Now that I have written this, I read previous conversations and it looks to > me like what I would like is what you had previously. > > I'm sorry if I complain too much, but I would like to see something like > this implemented, just not like you are proposing right now. It is too > messy for me and I know I wouldn't like it if I had to use it. > > Regards, > Kamil I also didn't pay close attention to the previous discussion, but reading the RFC I agree with all of this. The functionality proposed is good and needed, but the API is a mess. What Kamil suggests is far better, and fully commits to being OOPy. Given that the use case is for situations where you need a predictable and repeatable random sequence, such as Fibers or threads or such, going all-in on an object seems like the correct approach. One thing I'm not 100% clear on from the RFC, does this also deprecate random_int()/random_bytes()? Those are (AFAIK) unseeded, so they seem like they'd continue to serve their current purpose, but it's not clear from the RFC. Voting no for now, but I would welcome a resubmission with a cleaner API, even in this cycle. --Larry Garfield