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 <tekiela...@gmail.com>: > Hi Go Kudo, > > First, let me say that I believe we need such implementation in PHP and I > would like to see object scoped RNG as part of the standard. However, I > have voted no for a number of reasons. Let me list them from the > perspective of a noob PHP user. > > - 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_next(), rng_next64(). > Which one should I use? What is the difference between rng_next() > and rng_next64? > - 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. > - 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. > - 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. > - What is the default seed? Do I have to provide a seed each time? Why > can't the seed be done automatically? > - Signed? Unsigned? As far as I know, PHP doesn't have unsigned integers. > What's the real-life purpose of this flag? > - 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. > - 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. > > I would rather like to see a single class called RNG/Random that > implements RNG/RandomInterface. The constructor of the class would take 2 > arguments. The first is the algorithm with a default either MT or XORShift. > The second is an optional seed. If no seed is provided then the seed is > generated automatically like in mt_srand(). The class would then implement > methods like: nextInt(), nextDouble(), nextBytes(), arrayShuffle(), > stringShuffle(), randomArrayKeys(). I would keep the standard functions as > they are. Let them use MT by default. We could even deprecate them in > future if this takes off. > > This would make it painfully obvious what the class does and how to use > it. No more procedural code. I would also make the class final so that you > can't inherit from it, but that is highly opinion-based. > Now that I have written this, I read previous conversations and it looks > to me like what I would like is what you had previously. > > I'm sorry if I complain too much, but I would like to see something like > this implemented, just not like you are proposing right now. It is too > messy for me and I know I wouldn't like it if I had to use it. > > Regards, > Kamil >
