5 ms·

Because max value should be "mt_getrandmax()" instead of "PHP_INT_MAX", it just gets a 32 bit number then scales it up. see: http://php.net/manual/en/function.

Because max value should be "mt_getrandmax()" instead of "PHP_INT_MAX", it just gets a 32 bit number then scales it up. see: http://php.net/manual/en/function.mt-rand.php http://php.net/manual/en/function.mt-rand.php Under caution: The distribution of mt_rand() return values is biased towards even numbers on 64-bit builds of PHP when max is beyond 2^32. This is because if max is greater than the value returned by mt_getrandmax(), the output of the random number generator must be scaled up. edit: this post went from 5 points to 1, which I don't care about(in ~500 days I posted less than 10 times and I have ~35 points), but who downvotes documentation, seriously? -_-

3JPLW 11y ago
Why even accept ranges that span more than 2^32? That seems like an easy solution to a broken function. Also fun: echo "<?php echo mt_rand(-mt_getrandmax(), mt_getrandmax());" | php is always even on my PHP 5.5.20.
- poizan42 11y ago
  Why not generate two values from the underlying function and shift them into place if the range is larger than 2^32 -1? Oh well, ofc. because this is PHP which goes by the principle of most surprise.
  - TillE 11y ago
    Yes, that's exactly what sensible RNG interfaces do, like std::random in C++. If your underlying engine only produces 32 bits at a time, it'll grab two of them when you request a 64-bit type.
- TazeTSchnitzel 11y ago
  > Why even accept ranges that span more than 2^32? That seems like an easy solution to a broken function. It may never have been designed to. If it was written before 64-bit machines were commonplace, mt_getrandmax() would always be the same as PHP_INT_MAX.
_asummers 11y ago
While documented, that is surprising behavior. If it takes in an int, shouldn't it be able to take in PHP_INT_MAX? And shouldn't it yell at you instead of just silently going about its day?
- sneak 11y ago
  Almost everything in PHP is surprising behavior. And yes, in the eleventy billion cases where PHP should yell at you that it's doing something totally different than what you wanted, it instead just goes about its day silently.
  - KingMob 11y ago
    Which is why it was a great fit for MySQL, which would silently store invalid dates and truncate over-long strings with no warnings.
    - vog 11y ago
      This is so true. It is the main reason I switched to PostgreSQL and never looked back.
    - gmac 11y ago
      ... and accept nonsensical SQL queries, returning whatever it feels like.
    - mratzloff 11y ago
      You joke, but I'm pretty sure this is one of the reasons why that stack was so successful. Same principle behind HTML rendering. "It's displaying something, isn't it? Errors are only suggestions."
      - krick 11y ago
        I'm not so sure. It's kind of true for HTML (forgiveness was not "good" property of the format, but of the browser: 1 site works in one browser, but not in the other, and user will blame the browser, so let's display whatever the hell we can). But PHP in the early days was kinda handy (even though hacky) tool, allowing to use simple syntax to render HTML instead of custom Perl-scripts. And then it just got popular. MySQL was once actually superior open-source database, being more performant and simpler to setup and use than PostgreSQL. And then, once again, it just got popular. I don't think being faulty helped these technologies, although it sometimes is the case.
deleted 11y ago
[deleted]
jrgv 11y ago
There is a caution box in the description, which contains a different warning, and then the warning you have cited is in a second caution box in the "Notes" section, after the changelog and the examples. It doesn't surprise me that people might not notice the existence of that second warning. I believe that most developers wouldn't scroll down to read the changelog and the example if they think they understood what the function does from its description.
eonw 11y ago
no surprised about the down votes, i've seen a lot of logical explanations and correct responses get them. its almost like they would rather read drama then thoughtful answers.
smegel 11y ago
> Because max value should be "mt_getrandmax()" instead of "PHP_INT_MAX", it just gets a 32 bit number then scales it up. How does that answer anything?

3JPLW 11y ago

Why even accept ranges that span more than 2^32? That seems like an easy solution to a broken function. Also fun: echo "<?php echo mt_rand(-mt_getrandmax(), mt_getrandmax());" | php is always even on my PHP 5.5.20.

poizan42 11y ago
Why not generate two values from the underlying function and shift them into place if the range is larger than 2^32 -1? Oh well, ofc. because this is PHP which goes by the principle of most surprise.
- TillE 11y ago
  Yes, that's exactly what sensible RNG interfaces do, like std::random in C++. If your underlying engine only produces 32 bits at a time, it'll grab two of them when you request a 64-bit type.
TazeTSchnitzel 11y ago
> Why even accept ranges that span more than 2^32? That seems like an easy solution to a broken function. It may never have been designed to. If it was written before 64-bit machines were commonplace, mt_getrandmax() would always be the same as PHP_INT_MAX.

_asummers 11y ago

While documented, that is surprising behavior. If it takes in an int, shouldn't it be able to take in PHP_INT_MAX? And shouldn't it yell at you instead of just silently going about its day?

sneak 11y ago
Almost everything in PHP is surprising behavior. And yes, in the eleventy billion cases where PHP should yell at you that it's doing something totally different than what you wanted, it instead just goes about its day silently.
- KingMob 11y ago
  Which is why it was a great fit for MySQL, which would silently store invalid dates and truncate over-long strings with no warnings.
  - vog 11y ago
    This is so true. It is the main reason I switched to PostgreSQL and never looked back.
  - gmac 11y ago
    ... and accept nonsensical SQL queries, returning whatever it feels like.
  - mratzloff 11y ago
    You joke, but I'm pretty sure this is one of the reasons why that stack was so successful. Same principle behind HTML rendering. "It's displaying something, isn't it? Errors are only suggestions."
    - krick 11y ago
      I'm not so sure. It's kind of true for HTML (forgiveness was not "good" property of the format, but of the browser: 1 site works in one browser, but not in the other, and user will blame the browser, so let's display whatever the hell we can). But PHP in the early days was kinda handy (even though hacky) tool, allowing to use simple syntax to render HTML instead of custom Perl-scripts. And then it just got popular. MySQL was once actually superior open-source database, being more performant and simpler to setup and use than PostgreSQL. And then, once again, it just got popular. I don't think being faulty helped these technologies, although it sometimes is the case.

deleted 11y ago

[deleted]

jrgv 11y ago

There is a caution box in the description, which contains a different warning, and then the warning you have cited is in a second caution box in the "Notes" section, after the changelog and the examples. It doesn't surprise me that people might not notice the existence of that second warning. I believe that most developers wouldn't scroll down to read the changelog and the example if they think they understood what the function does from its description.

eonw 11y ago

no surprised about the down votes, i've seen a lot of logical explanations and correct responses get them. its almost like they would rather read drama then thoughtful answers.

smegel 11y ago

> Because max value should be "mt_getrandmax()" instead of "PHP_INT_MAX", it just gets a 32 bit number then scales it up. How does that answer anything?