Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119256
MIME-Version: 1.0
References: <CAMs36HdC6k0pjvjiXJDJhnUjSPeOnGSUFMn0FmyE2e0fZ1cCdQ@mail.gmail.com>
 <046f5d6d-772b-15b5-e162-9309f67eba97@bastelstu.be>
In-Reply-To: <046f5d6d-772b-15b5-e162-9309f67eba97@bastelstu.be>
Date: Wed, 11 Jan 2023 07:03:23 +0900
Message-ID: <CAMs36Hf5aVHAw1fV=igS1rx9inib=wiZvxBJHgX2C1R2Lyn28w@mail.gmail.com>
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000016a74805f1f00e84"
Subject: Re: [PHP-DEV] ext-random: add random_float() ?
From: g-kudo@colopl.co.jp (Go Kudo)

--00000000000016a74805f1f00e84
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

2022=E5=B9=B412=E6=9C=8829=E6=97=A5(=E6=9C=A8) 22:25 Tim D=C3=BCsterhus <ti=
m@bastelstu.be>:

> 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=C3=A9d=
=C3=A9ric
> 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=C3=BCsterhus
>

Hi Tim

Thank you for the clear explanation. I generally understood the intent. And
once again I recognized that floating point random numbers are difficult to
handle.

I agree that the addition of the random_float() function is inappropriate.
However, with the goal of deprecating it in PHP 8.3 and deprecating RNGs
with virtual machine dependent state in PHP 9.x, I think we need to provide
a useful replacement for the lcg_value() function.

Do you have any good ideas on this?

Most likely, since the random numbers generated by lcg_value() are of low
quality and do not appear to be used very often, one idea would be to
simply remove it. However, I believe that the absence of an alternative
function is likely to generate negative opinions about its elimination.

Regards,
Go Kudo

--00000000000016a74805f1f00e84--