Yes, I know the reason why we use MT19937 as the name, but this is not
really very user-friendly name. The actual algorithm could be documented in
the PHP manual but the name could be better. The problem with this name is
that most users simply don't care about the algorithm being used. At least
The RFCs are in limbo, but we are currently thinking of including the
following RNGs in the proposal
- XorShift128Plus
- MT19937 (for compatibility)
- MT19937_64 (for more entropy and wider range)
While it is clear that MT19937 is simply MersenneTwister, it is not
accurate since there is
2021年9月23日(木) 2:05 Dan Ackroyd :
> Go Kudo wrote:
> > Dan Ackroyd wrote:
> >> you can _simply_ include ext/random/random.h." sounds pretty
> >> dismissive of causing possibly unneeded work for downstream projects.
> >
> > The point I was trying to make was that while BC Breaks do occur, they
>
Please don't add more answers to the class name. There is already going to
be a backlash if we name it "MT19973" instead of "MersenneTwister"
I had misunderstood this for a long time. Now I understand.
This is certainly something to think about.
However, I think we also need to consider compatibility. How about
something like the following?
```php
:
> On Thu, Sep 9, 2021 at 6:31 AM Go Kudo wrote:
>
>> Hi Nikita, sorry for the late
On Thu, Sep 9, 2021 at 6:31 AM Go Kudo wrote:
> Hi Nikita, sorry for the late reply.
>
> This is a difficult problem. For now, MT19937 is left for compatibility.
> In other words, if you don't need compatibility, there is no benefit to
> using it.
>
> What about implementing both a new MT and a
Go Kudo wrote:
> Dan Ackroyd wrote:
>> you can _simply_ include ext/random/random.h." sounds pretty
>> dismissive of causing possibly unneeded work for downstream projects.
>
> The point I was trying to make was that while BC Breaks do occur, they are
> very easy to solve.
I've found it useful
Hi Nikita, sorry for the late reply.
This is a difficult problem. For now, MT19937 is left for compatibility. In
other words, if you don't need compatibility, there is no benefit to using
it.
What about implementing both a new MT and a compatible MT? A compatible MT
would have the following
On Thu, Sep 2, 2021 at 5:10 PM Go Kudo wrote:
> Hi Internals.
>
> Expanded from the previous RFC and changed it to an RFC that organizes the
> whole PHP random number generator. Also, the target version has been
> changed to 8.2.
>
> https://wiki.php.net/rfc/rng_extension
>
On Sat, Sep 4, 2021 at 10:57 PM Marc wrote:
>
> On 9/2/21 5:10 PM, Go Kudo wrote:
> > Hi Internals.
> >
> > Expanded from the previous RFC and changed it to an RFC that organizes
> the
> > whole PHP random number generator. Also, the target version has been
> > changed to 8.2.
> >
> >
Thanks marc.
> "shuffleString()" works on byte level and so it should be
"shuffleBytes()".
Hmm. This may be a difficult problem related to the PHP language
specification. As with `str_shuffle()`, most people will probably use it to
shuffle strings. People who want to shuffle binaries are likely
This may not have been the best way to put it. The point I was trying to
make was that while BC Breaks do occur, they are very easy to solve.
The impact on downstream projects will be significant, and there may be
many extensions affected, since this change concerns a frequently used RNG
feature.
On 9/2/21 5:10 PM, Go Kudo wrote:
Hi Internals.
Expanded from the previous RFC and changed it to an RFC that organizes the
whole PHP random number generator. Also, the target version has been
changed to 8.2.
https://wiki.php.net/rfc/rng_extension
https://github.com/php/php-src/pull/7453
On Fri, 3 Sept 2021 at 18:41, Go Kudo wrote:
>
> Nikita wrote:
>> this one also moves all of the existing RNG-related functionality
>> from ext/standard to ext/random.
>
> There are several reasons for this.
>
> - The `random` extension name is already used by ext/standard and may
> interfere
Thanks nikita.
> ext/standard to ext/random. Why does it do this?
There are several reasons for this.
- The `random` extension name is already used by ext/standard and may
interfere with the build system.
- Due to the namespace rules for new extensions, it is inappropriate to
rename an
On Thu, Sep 2, 2021 at 5:10 PM Go Kudo wrote:
> Hi Internals.
>
> Expanded from the previous RFC and changed it to an RFC that organizes the
> whole PHP random number generator. Also, the target version has been
> changed to 8.2.
>
> https://wiki.php.net/rfc/rng_extension
>
> I'm still unclear how I'd write my own NumberGenerator right now. I
mean, I can extend the class, but I don't have a sense for what I'd do with
it for non-testing/trivial implementations. You say it's using an internal
function to generate numbers, but in user space what would I do with that?
On Fri, Sep 3, 2021, at 8:55 AM, Go Kudo wrote:
> Thank you.
>
> > Why is the number generator a parent class rather than an interface?
>
> This is an implementation limitation. I could not find a way to define my
> own object handler in interface.
> As Nikita pointed out in a previous
My apologies. I had skipped one.
> And either way it needs more clarity about how you'd write one for reals.
Added a simple example comparing it to mt_rand. What do you think of this?
2021年9月3日(金) 3:26 Larry Garfield :
> On Thu, Sep 2, 2021, at 10:10 AM, Go Kudo wrote:
> > Hi Internals.
> >
>
Thank you.
> Why is the number generator a parent class rather than an interface?
This is an implementation limitation. I could not find a way to define my
own object handler in interface.
As Nikita pointed out in a previous suggestion, the NumberGenerator now
uses php_random_ng_algo_user to
On Thu, Sep 2, 2021, at 10:10 AM, Go Kudo wrote:
> Hi Internals.
>
> Expanded from the previous RFC and changed it to an RFC that organizes the
> whole PHP random number generator. Also, the target version has been
> changed to 8.2.
>
> https://wiki.php.net/rfc/rng_extension
>
21 matches
Mail list logo
