4 ms·

Probably a matter of mitigating risk. Despite its drawbacks, rand() is used a LOT and works...well, "good enough". In the interest of making sure the code you

by Mark_B 17y ago

Probably a matter of mitigating risk. Despite its drawbacks, rand() is used a LOT and works...well, "good enough". In the interest of making sure the code you wrote for PHP3 will work on current/future versions and not have anything unexpected happen.

zokier 17y ago
I would like to see the code that breaks if PRNG is swapped. I mean, like is there code out there that relies on the unrandomness of current rand?
- jacquesm 17y ago
  Testsets + known output, spots where the PRNG has been used as part of the seed driving cryptographic code. The fact that a given seed makes your program deterministic is a great way to 'lock' the variation that a random generator would otherwise give you. So, say you have a series of steps that produce a result given a random number as the seed. You come up with a bunch of cases where the run output has been saved and checked by hand to conform, you now use that output to verify against when maintaining the software. If you should change the behavior of the PRNG then output will change and the test will break. A database with passwords that were 'encrypted' (I use the word loosely) using the PRNG with parts of the password as the seed. If you change the PRNG under water none of those users can log in. There are probably lots of other examples, these are just two simple scenarios where code would break.
  - DrJokepu 17y ago
    As far as I see these examples are all scandalous abuses of undocumented implementation details. While I can't be bothered to look up the actual documentation, I'm almost 100% sure that it's not guaranteed that PHP's rand() will always yield the same results for the same seed. But if it is, well, that would be a peculiar example of shortsighted language framework design.
    - jacquesm 17y ago
      > I'm almost 100% sure that it's not guaranteed that PHP's rand() will always yield the same results for the same seed. That's the whole point of having a seed, isn't it ? see the Periodicity entry: http://en.wikipedia.org/wiki/Pseudorandom_number_generator http://en.wikipedia.org/wiki/Pseudorandom_number_generator and http://www.php.net/manual/en/function.srand.php http://www.php.net/manual/en/function.srand.php Does not make any mention of the behavior you cite, if you can't be bothered to look it up why bring it up in the first place ?
      - DrJokepu 17y ago
        All I'm saying that while it is indeed true that having a seed implies a deterministic behaviour, this should be an implementation detail that should not be exposed to the the users of the interface.
        jacquesm 17y ago
        Either I'm not following you, or you are not clear. Or both ;) It is meant to work that way, for precisely the kind of reasons I outlined above. Say you are writing a poker program. At the beginning of every game you seed the random number generator, you save the seed. Halfway through a test you find a bug in the program. You fix the bug (you think) and you make a test case for the fix. You run the test case with the restored random seed to see if the bug is actually under control and does not influence any other part of the game up to there. And so on. That's clearly documented and very common use. If it wouldn't be like that you'd have to play poker until the cows came home in the hope that one day that same sequence of play would occur.
        philh 17y ago
        What DrJokepu may have been getting at is that the implementation of rand() itself is not guaranteed. Expecting it not to change in future versions of the library is dubious.
        17y ago

by Mark_B 17y ago

zokier 17y ago

I would like to see the code that breaks if PRNG is swapped. I mean, like is there code out there that relies on the unrandomness of current rand?

jacquesm 17y ago
Testsets + known output, spots where the PRNG has been used as part of the seed driving cryptographic code. The fact that a given seed makes your program deterministic is a great way to 'lock' the variation that a random generator would otherwise give you. So, say you have a series of steps that produce a result given a random number as the seed. You come up with a bunch of cases where the run output has been saved and checked by hand to conform, you now use that output to verify against when maintaining the software. If you should change the behavior of the PRNG then output will change and the test will break. A database with passwords that were 'encrypted' (I use the word loosely) using the PRNG with parts of the password as the seed. If you change the PRNG under water none of those users can log in. There are probably lots of other examples, these are just two simple scenarios where code would break.
- DrJokepu 17y ago
  As far as I see these examples are all scandalous abuses of undocumented implementation details. While I can't be bothered to look up the actual documentation, I'm almost 100% sure that it's not guaranteed that PHP's rand() will always yield the same results for the same seed. But if it is, well, that would be a peculiar example of shortsighted language framework design.
  - jacquesm 17y ago
    > I'm almost 100% sure that it's not guaranteed that PHP's rand() will always yield the same results for the same seed. That's the whole point of having a seed, isn't it ? see the Periodicity entry: http://en.wikipedia.org/wiki/Pseudorandom_number_generator http://en.wikipedia.org/wiki/Pseudorandom_number_generator and http://www.php.net/manual/en/function.srand.php http://www.php.net/manual/en/function.srand.php Does not make any mention of the behavior you cite, if you can't be bothered to look it up why bring it up in the first place ?
    - DrJokepu 17y ago
      All I'm saying that while it is indeed true that having a seed implies a deterministic behaviour, this should be an implementation detail that should not be exposed to the the users of the interface.
      - jacquesm 17y ago
        Either I'm not following you, or you are not clear. Or both ;) It is meant to work that way, for precisely the kind of reasons I outlined above. Say you are writing a poker program. At the beginning of every game you seed the random number generator, you save the seed. Halfway through a test you find a bug in the program. You fix the bug (you think) and you make a test case for the fix. You run the test case with the restored random seed to see if the bug is actually under control and does not influence any other part of the game up to there. And so on. That's clearly documented and very common use. If it wouldn't be like that you'd have to play poker until the cows came home in the hope that one day that same sequence of play would occur.
        philh 17y ago
        What DrJokepu may have been getting at is that the implementation of rand() itself is not guaranteed. Expecting it not to change in future versions of the library is dubious.
        17y ago