2022年12月29日(木) 22:25 Tim Düsterhus <t...@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é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 >
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
