Everything

php

libc and random functions

php.internals

Keryx Web

19 years ago

I do not know if this post made it to the list a while ago. No one
answered and i see I used the wrong account to send it. Please forgive
me if this is a redundant re-post.


This is a suggestion I think would not be too hard to implement:

Skip libc for all random functions. As I see it there is no reason to
keep it. I can't think of any application that would break if rand()
would produce better random results at a higher speed.

So basically what I am saying is this: Implement the mersenne twister in
the back of all random functions.

1. Make rand() an alias to mt_rand()
2. Make srand() an alias to mt_srand() (And since they are redundant
give an E_STRICT?)
3. Make getrandmax() an alias to mt_getrandmax()
4. Have array_rand() implement MT in the back (if it is not doing so
already)



Lars Gunther

P.S. For an introduction to who I am one might read:
http://www.webstandards.org/action/edutf/interviews/gunther-en/
and look at
http://www.flickr.com/photos/keryxgunther/143376264/

Ilia A.

19 years ago

Do you have a patch?

On 18-Jul-07, at 2:20 PM, Keryx Web wrote:

> I do not know if this post made it to the list a while ago. No one
> answered and i see I used the wrong account to send it. Please
> forgive me if this is a redundant re-post.
>
>
> This is a suggestion I think would not be too hard to implement:
>
> Skip libc for all random functions. As I see it there is no reason
> to keep it. I can't think of any application that would break if
> rand() would produce better random results at a higher speed.
>
> So basically what I am saying is this: Implement the mersenne
> twister in the back of all random functions.
>
> 1. Make rand() an alias to mt_rand()
> 2. Make srand() an alias to mt_srand() (And since they are
> redundant give an E_STRICT?)
> 3. Make getrandmax() an alias to mt_getrandmax()
> 4. Have array_rand() implement MT in the back (if it is not doing
> so already)
>
>
>
> Lars Gunther
>
> P.S. For an introduction to who I am one might read:
> http://www.webstandards.org/action/edutf/interviews/gunther-en/
> and look at
> http://www.flickr.com/photos/keryxgunther/143376264/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Ilia Alshanetsky

Keryx Web

19 years ago

Ilia Alshanetsky wrote:

> Do you have a patch?

Also @Antony Dovgal in the "let blocks" thread

Short answer: No.

The reason I posted my suggestions on this list was that a while ago I
had a few ideas as to how PHP could be improved. A seasoned PHP
developer suggested that I'd take my suggestions to this list.

As I have no "commit karma" - as it has been dubbed elsewhere - I have
tried to be polite and keep a low profile, only speaking out when I
thought that my perspective could be of value to the discussion at hand.

Now I have two questions:

(1) Is it considered bad form to make feature suggestions on this list,
even though I am not in the position to make any patches myself?

(2) If so, can anyone point me to the place where such a feature request
might be made?

And now - hypothetically speaking - maybe I could find some time during
this autumn to actually learn a bit more C and make a patch. Wouldn't it
be better if I made a patch that the community thought worthwhile and
not spend my time developing something none ever would commit?

Just having someone say: "That sounds like a good idea", would be an
encouragement for such an undertaking.


Lars Gunther

David Coallier

19 years ago

On 7/19/07, Keryx Web <webmaster@keryx.se> wrote:

> Ilia Alshanetsky wrote:
> > Do you have a patch?
>
> Also @Antony Dovgal in the "let blocks" thread
>
> Short answer: No.
>
> The reason I posted my suggestions on this list was that a while ago I
> had a few ideas as to how PHP could be improved. A seasoned PHP
> developer suggested that I'd take my suggestions to this list.
>
> As I have no "commit karma" - as it has been dubbed elsewhere - I have
> tried to be polite and keep a low profile, only speaking out when I
> thought that my perspective could be of value to the discussion at hand.
>
> Now I have two questions:
>
> (1) Is it considered bad form to make feature suggestions on this list,
> even though I am not in the position to make any patches myself?
>
> (2) If so, can anyone point me to the place where such a feature request
> might be made?
>
> And now - hypothetically speaking - maybe I could find some time during
> this autumn to actually learn a bit more C and make a patch. Wouldn't it
> be better if I made a patch that the community thought worthwhile and
> not spend my time developing something none ever would commit?
>
> Just having someone say: "That sounds like a good idea", would be an
> encouragement for such an undertaking.
>
>
> Lars Gunther
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Side note for you Lars, I have a patch for the initial request on this
thread about rand -> mt_rand, etc.

I'm just making sure i'm not breaking any extensions, and then I'll
send it on the list :) Should be in about an hour or so.

--
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18

Antony Dovgal

19 years ago

On 19.07.2007 17:41, Keryx Web wrote:

> Ilia Alshanetsky wrote:
>> Do you have a patch?
>
> Also @Antony Dovgal in the "let blocks" thread
>
> Short answer: No.
>
> The reason I posted my suggestions on this list was that a while ago I
> had a few ideas as to how PHP could be improved.

What I don't understand about the crypt thing you propose - is what problem are you trying to fix this way?

If there are no problems, then please don't improve anything not broken.
"No reasons to keep it" is wrong, there is at least one reason to keep it as is - it works fine.

--
Wbr,
Antony Dovgal

David Coallier

19 years ago

On 7/19/07, Antony Dovgal <antony@zend.com> wrote:

> On 19.07.2007 17:41, Keryx Web wrote:
> > Ilia Alshanetsky wrote:
> >> Do you have a patch?
> >
> > Also @Antony Dovgal in the "let blocks" thread
> >
> > Short answer: No.
> >
> > The reason I posted my suggestions on this list was that a while ago I
> > had a few ideas as to how PHP could be improved.
>
> What I don't understand about the crypt thing you propose - is what problem are you trying to fix this way?
>
> If there are no problems, then please don't improve anything not broken.
> "No reasons to keep it" is wrong, there is at least one reason to keep it as is - it works fine.
>
> --
> Wbr,
> Antony Dovgal
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Here are three patches against HEAD [1], 5_2 [2] and the pecl
repository [3] (Do not shout just yet, I'll explain).

The idea of the patches are pretty simple, aliasing rand, srand,
getrandmax to mt_rand, mt_srand, and mt_getrandmax. The goal is simply
having a better number generation. Nothing fancier, or more different,
but simply it. It works great (compiling great against 5_2, HEAD) and
Crisitan Rodriguez also tried the compilation.

After a bit of discussion with Jani, I came to realize that keeping
the wrapper macro for php_rand, php_srand is plain useless. Yes some
pecl extensions do rely on them (and for those who do, I also provided
a patch [3]). We both realized that there's not many extensions
relying on php_rand and php_srand thus removed it completely..

Here are the patches:

[1] HEAD : http://dev.agoraproduction.com/php/php6/head-mt-changes.diff
[2] 5_2     : http://dev.agoraproduction.com/php/5_2/5.2-mt-changes.diff
[3] PECL : http://dev.agoraproduction.com/php/php6/pecl-mt-changes.diff


Please note that the mt-changes patches are not only changing
ext/standard/* but also the ext/* relying on them. (soap, mcrypt) but
also a small change in main/reentrancy.c both in 5_2 and HEAD.

Thanks,

--
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18

David Coallier

19 years ago

On 7/19/07, David Coallier <davidc@php.net> wrote:

> On 7/19/07, Antony Dovgal <antony@zend.com> wrote:
> > On 19.07.2007 17:41, Keryx Web wrote:
> > > Ilia Alshanetsky wrote:
> > >> Do you have a patch?
> > >
> > > Also @Antony Dovgal in the "let blocks" thread
> > >
> > > Short answer: No.
> > >
> > > The reason I posted my suggestions on this list was that a while ago I
> > > had a few ideas as to how PHP could be improved.
> >
> > What I don't understand about the crypt thing you propose - is what problem are you trying to fix this way?
> >
> > If there are no problems, then please don't improve anything not broken.
> > "No reasons to keep it" is wrong, there is at least one reason to keep it as is - it works fine.
> >

Sorry I did not quite answer your question in my email + patch. Yes it
works correctly as it is, however, with this patch, the random numbers
being generated are using an algorithm (Mersenne Twister) that allows
us to give more randomness if I may use the term. So it simply doesn't
*fix* anything, but improves random number generation.

There are various reasons why people are using random generated
numbers and mt_ is more random than rand*. Simply it. It does not
**fix** something that is broken, simply improves it.

Yes we could still use a rock to make fire, and it still works fine,
but might as well use matches, lenses or lighters. It's more effective
and faster.

> > --
> > Wbr,
> > Antony Dovgal
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
> Here are three patches against HEAD [1], 5_2 [2] and the pecl
> repository [3] (Do not shout just yet, I'll explain).
>
> The idea of the patches are pretty simple, aliasing rand, srand,
> getrandmax to mt_rand, mt_srand, and mt_getrandmax. The goal is simply
> having a better number generation. Nothing fancier, or more different,
> but simply it. It works great (compiling great against 5_2, HEAD) and
> Crisitan Rodriguez also tried the compilation.
>
> After a bit of discussion with Jani, I came to realize that keeping
> the wrapper macro for php_rand, php_srand is plain useless. Yes some
> pecl extensions do rely on them (and for those who do, I also provided
> a patch [3]). We both realized that there's not many extensions
> relying on php_rand and php_srand thus removed it completely..
>
> Here are the patches:
>
> [1] HEAD : http://dev.agoraproduction.com/php/php6/head-mt-changes.diff
> [2] 5_2     : http://dev.agoraproduction.com/php/5_2/5.2-mt-changes.diff
> [3] PECL : http://dev.agoraproduction.com/php/php6/pecl-mt-changes.diff
>
>
> Please note that the mt-changes patches are not only changing
> ext/standard/* but also the ext/* relying on them. (soap, mcrypt) but
> also a small change in main/reentrancy.c both in 5_2 and HEAD.
>
> Thanks,
>
> --
> David Coallier,
> Founder & Software Architect,
> Agora Production (http://agoraproduction.com)
> 51.42.06.70.18
>

--
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18

Johannes Schlueter

19 years ago

Hi David,

On Thu, 2007-07-19 at 13:09 -0400, David Coallier wrote:

> After a bit of discussion with Jani, I came to realize that keeping
> the wrapper macro for php_rand, php_srand is plain useless. Yes some
> pecl extensions do rely on them (and for those who do, I also provided
> a patch [3]). We both realized that there's not many extensions
> relying on php_rand and php_srand thus removed it completely..

I don't think that removing APIs during a point release is a good thing.
Even when you grepped through PECL it doesn't mean that not more
extensions are using these functions. I'm fine with removing it from
HEAD, if there's an replacement but not for a bugfix release.

johannes

David Coallier

19 years ago

I totally agree. the only reasn for the 5-2 patch was for people to test

On 7/19/07, Johannes Schlüter <johannes@php.net> wrote:

> Hi David,
>
> On Thu, 2007-07-19 at 13:09 -0400, David Coallier wrote:
> > After a bit of discussion with Jani, I came to realize that keeping
> > the wrapper macro for php_rand, php_srand is plain useless. Yes some
> > pecl extensions do rely on them (and for those who do, I also provided
> > a patch [3]). We both realized that there's not many extensions
> > relying on php_rand and php_srand thus removed it completely..
>
> I don't think that removing APIs during a point release is a good thing.
> Even when you grepped through PECL it doesn't mean that not more
> extensions are using these functions. I'm fine with removing it from
> HEAD, if there's an replacement but not for a bugfix release.
>
> johannes
>
>

--
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18

Pierre Joye

19 years ago

On 7/19/07, davidc@php.net <davidc@php.net> wrote:

> I totally agree. the only reasn for the 5-2 patch was for people to test

You can simply keep the old functions for 5.2 and remove them in HEAD.

We can't remove an API (or change it) in a point release, it is a full
breakage (BC and binary).

--Pierre

David Coallier

19 years ago

On 7/19/07, Pierre <pierre.php@gmail.com> wrote:

> On 7/19/07, davidc@php.net <davidc@php.net> wrote:
> > I totally agree. the only reasn for the 5-2 patch was for people to test
>
> You can simply keep the old functions for 5.2 and remove them in HEAD.
>
> We can't remove an API (or change it) in a point release, it is a full
> breakage (BC and binary).
>
>
> --Pierre
>

I agree, this was mainly for HEAD, but just wanted to give an
opportunity to people to test it.

HEAD it is :)

--
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18