Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113947 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 6180 invoked from network); 5 Apr 2021 00:23:35 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 5 Apr 2021 00:23:35 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 3B91E1804DB for ; Sun, 4 Apr 2021 17:22:13 -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.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com [209.85.218.51]) (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 ; Sun, 4 Apr 2021 17:22:12 -0700 (PDT) Received: by mail-ej1-f51.google.com with SMTP id l4so14711107ejc.10 for ; Sun, 04 Apr 2021 17:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=w8kQKl40VMZ1Q8af+1yX9UtMZrKuui+3zK+c/rPNRtI=; b=iqqbdNz320GnHOLz5q7Yb/F2E05wN1ujibogbLL8xZr05cwsqpwXcqPsh8RZXpoCgB x0ZKLCwSuqvQZYmGE7h3srGwlw/kys4YXIY60/KzioKgA+841lkIHxg6ua9Z+3o8F8FP UJqXJKImjgWGacvlhUd78HgbjyCKADU30L7oEzBkF6kR5jNiSdetnX94s09P/3HbGODU xd5cYhM+iouE/Cgj1YVkaoVa/fDL2N4Lavb9/vAM/4VFEYeHTn7WQzRVyUPb8mAQ2ePh 5q9liqidIwRSxiA3edGEzOLMu3CC0ZoRY1qkKzi8LXMSzQUUwgIcX2bKzvSTIBHWH5x5 g1Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=w8kQKl40VMZ1Q8af+1yX9UtMZrKuui+3zK+c/rPNRtI=; b=V20J1qUMbAXvrImgDp5eE0Dy9G8ywzQziw7z0MK1FYw5FCb6XqaoGdVsFNmdOc9ODD sCOg/zAS3KAUXm/rw86qBuKhDcxuwZxosA3WdJ61aPPF6STq+YCABux2Gm9Kx6LB+Ddt kftoc2lZCPNd9amI28Zugx9LZcOByAW4I/tMrUKTTJJHjEO5NH1DVWCb9N9OcrqQ7REF CMLDJVchaIaGIaSfAgYhOi1WkgA5+0BKQT+pFLcSGNkruZjt/L8SSQXqoSWVHNtgnVUC BWCAdSEqYhDwhSWYNRDhrrQ7HzMZrscurJqCQ/E9TsYwNRiOKPrAk0FiniOwgmAYY1QM Az6A== X-Gm-Message-State: AOAM530l/NXWJrL1TzYCHv+wszlvAl2DyS2Rgqiq/k7iwhcH+LmFPYP9 55A+zqa1orN8Y5PbLH389l030Kg5ke6a9KrpeII= X-Google-Smtp-Source: ABdhPJzA1SOYhL6DvwPXKaj+pUOXuUSuJlGKEKN6wkZFlswwBDn8p8k6z+B1KiskwCdVLN7tzf2nmlgguuvLFTomx4c= X-Received: by 2002:a17:907:da4:: with SMTP id go36mr5551285ejc.245.1617582125916; Sun, 04 Apr 2021 17:22:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 5 Apr 2021 09:21:54 +0900 Message-ID: To: Kamil Tekiela , PHP internals Content-Type: multipart/alternative; boundary="00000000000002a69e05bf2eb0ab" Subject: Re: [PHP-DEV] [VOTE] Object scoped RNG implementation From: zeriyoshi@gmail.com (Go Kudo) --00000000000002a69e05bf2eb0ab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This RFC seems to have a lot of problems. But I would like to answer the question first. > - 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_ This was done with the intention of lightening the burden of RNG implementation in PHP. At the time of the discussion, it was assumed that RNGInterface would also provide alternative functions such as `shuffle()` and `array_rand()`. > - 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. The class name is based on the random number generation algorithm. As the namespace is RNG, I think this is straightforward enough. > 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. Basically, it assumes that XorShift128+ is used. MT19937 is implemented in case you need to reproduce the behavior of traditional MT. > 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. As I have said many times before, this was the original implementation plan= . The PECL orng extension provides functionality that is largely based on this. > Signed? Unsigned? As far as I know, PHP doesn't have unsigned integers. What's the real-life purpose of this flag? The idea is to use `RNG\MT19937` and `rng_next()` to make them behave the same as `mt_srand()` and `mt_rand()`. This will allow all `mt_srand()` to be replaced by the new object-based RNG implementation. > 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. This can be useful when you want to generate results from a pre-determined random number table. See this test case. https://github.com/php/php-src/blob/6834426452b151c36e4d1e292ad997d6bcf139a= e/ext/standard/tests/rng/function_rng_bytes_string.phpt > 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. This is the cost of increased versatility. I'm not so convinced about this either. Calling `next64()` in a 32bit environment will give incorrect results. `rng_next64()` determines the execution environment beforehand, and throws ValueError if it is not available. Since it is difficult to expect such "error checking" from a userland implementation, this is the way it is. This RFC ballot should be rescinded. There was too little discussion beforehand. I will create a new proposal based on the feedback I received. I would appreciate your active input so that this does not happen during the voting phase. 2021=E5=B9=B44=E6=9C=883=E6=97=A5(=E5=9C=9F) 6:56 Kamil Tekiela : > 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 wh= at > 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 arra= y > 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 callin= g > ->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 XORShif= t. > 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 implemen= t > methods like: nextInt(), nextDouble(), nextBytes(), arrayShuffle(), > stringShuffle(), randomArrayKeys(). I would keep the standard functions a= s > 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 yo= u > 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 > --00000000000002a69e05bf2eb0ab--