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.
- Make
rand()an alias tomt_rand() - Make
srand()an alias tomt_srand()(And since they are redundant
give an E_STRICT?) - Make
getrandmax()an alias tomt_getrandmax() - 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/
Do you have a patch?
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.
- Make
rand()an alias tomt_rand()- Make
srand()an alias tomt_srand()(And since they are
redundant give an E_STRICT?)- Make
getrandmax()an alias tomt_getrandmax()- 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 Alshanetsky
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
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
--
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
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
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--
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
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--
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.diffPlease 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
Hi David,
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
I totally agree. the only reasn for the 5-2 patch was for people to test
Hi David,
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
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 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