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/6834426452b151c36e4d1e292ad997d6bcf139ae/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年4月3日(土) 6:56 Kamil Tekiela <tekiela246@gmail.com>:
