Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119213
Message-ID: <046f5d6d-772b-15b5-e162-9309f67eba97@bastelstu.be>
Date: Thu, 29 Dec 2022 14:25:00 +0100
MIME-Version: 1.0
Content-Language: en-US
To: Go Kudo <g-kudo@colopl.co.jp>, internals@lists.php.net
References: <CAMs36HdC6k0pjvjiXJDJhnUjSPeOnGSUFMn0FmyE2e0fZ1cCdQ@mail.gmail.com>
In-Reply-To: <CAMs36HdC6k0pjvjiXJDJhnUjSPeOnGSUFMn0FmyE2e0fZ1cCdQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] ext-random: add random_float() ?
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

Hi

On 12/20/22 07:27, Go Kudo wrote:
> Now that my work is done, I was thinking about a proposal for a sunsetting
> of existing functions for PHP 8.3 based on the features introduced in
> ext-random, and I realized that there is no alternative to `lcg_value()`.
> 
> Essentially, this could be completely replaced by
> Random\Randomizer::getFloat(), but there are easier `random_int()` and
> `random_bytes()` functions for ints and strings.
> 
> The Randomizer may be overkill and complicated for PHP use cases where
> random number reproducibility is not required in many cases.
> 
> So, why not add a `random_float(): float` function? This function, like the
> others, uses CSPRNG and returns a value between 0.0 and 1.0. This behavior
> is `Closed` `Closed`.
> 
> Opinions are welcome.

I'm not convinced that a random_float() function is a good addition. 
Especially not with the proposed behavior:

1. Using the (0, 1, ClosedClosed) behavior does neither match 
Randomizer::nextFloat(), nor Randomizer::getFloat().

2. I consider the ClosedOpen behavior to be the "correct" default, 
because the interval can then be cleanly split into equally sized 
subintervals.

--------------------

But even when random_float() would work like Randomizer::nextFloat() 
(i.e. (0, 1, ClosedOpen)), I would not consider this a good addition:

Users would likely attempt to scale the returned value to arbitrary 
ranges using the `($min + random_float() * ($max - $min))` construction, 
instead of using Randomizer::getFloat().

As per Drawing Random Floating-Point Numbers from an Interval. Frédéric 
Goualard, ACM Trans. Model. Comput. Simul., 32:3, 2022 this construction 
is unsafe, because is is both biased and also may return values outside 
the expected interval.

--------------------

So random_float() would rather need to behave like 
Randomizer::getFloat() instead of Randomizer::nextFloat() and then it 
would not be much simpler than using the Randomizer class directly. I 
further expect that needing to generate random floats is much rarer than 
needing to generate random integers or random bytes (for tokens), thus 
having convenience functions for those two, but not floats is acceptable 
and keeps the API surface simple, making it easier to document all the 
gotchas. Users can add convenience wrappers themselves.

Best regards
Tim Düsterhus