Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112930 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 4437 invoked from network); 19 Jan 2021 17:29:41 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 19 Jan 2021 17:29:41 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 7665B1804AA for ; Tue, 19 Jan 2021 09:09:26 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_20,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from wp160.webpack.hosteurope.de (wp160.webpack.hosteurope.de [80.237.132.167]) (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 ; Tue, 19 Jan 2021 09:09:24 -0800 (PST) Received: from ip5f5bd202.dynamic.kabel-deutschland.de ([95.91.210.2] helo=[192.168.178.29]); authenticated by wp160.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1l1uVO-0000O1-Gr; Tue, 19 Jan 2021 18:09:22 +0100 User-Agent: Microsoft-MacOutlook/16.45.21011103 Date: Tue, 19 Jan 2021 18:09:21 +0100 To: Nikita Popov , Go Kudo CC: PHP internals Message-ID: <83B61661-90A6-48E8-8FF4-A1D9D972438D@mabe.berlin> Thread-Topic: [PHP-DEV] Re: [RFC] Object-scope RNG implementation References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-bounce-key: webpack.hosteurope.de;marc@mabe.berlin;1611076166;c89b8a00; X-HE-SMSGID: 1l1uVO-0000O1-Gr Subject: Re: [PHP-DEV] Re: [RFC] Object-scope RNG implementation From: marc@mabe.berlin (Marc Bennewitz) =EF=BB=BFAm 19.01.21, 17:20 schrieb "Nikita Popov" : * 64-bit: I looked over your implementation, and I think your approach = to handling 64-bits is correct. You only call next64() if the requested ra= nge is larger than 32-bit, and that can only happen on 64-bit systems, thus guaranteeing consistency of results (where they can be consistent at al= l). What I'm unsure about is the way this gets exposed to userland via next= () and next64() methods. I think fetching of 64-bit values is mainly interesting as an internal optimization, and not so much important to b= e part of the RNGInterface API. The user is intended to get numbers via rng_rand(), not by directly calling next(). A possibility here would be= to drop the RNG64Interface and next64() method, have next() always return 32-bit, but retain the internal next64 API. For this to make sense, we'= d need two subsequent internal next() calls to return the same data as a single next64() call (i.e. store the result and first return one half t= hen the other). Would this make sense to you? Wouldn't it make more sense to provide different classes for the algorithm = instead of two next/64 methods or limiting it? Like: * class MT19937 (system depending) * class MT19937_32 (32bit version) * class MT19937_64 (64bit version - not available on 32bit) This way the user can take the algorithm that matches best his requirements= . Marc Regards, Nikita