in reply to Re^5: Late PM, 12/24/2014 & all year long
in thread Late PM, 12/24/2014 & all year long

l ttyaMeos arrCsrihm!!l

With my perls, the original one-liner works as intended for 5.8.8 up to and including 5.18.0.
But with 5.20.0 I get the same as you.

The srand documentation contains this:
However, there are a few situations where programs are likely to want to call "srand". One is for generating predictable results, generally for testing or debugging. There, you use "srand($seed)", with the same $seed each time.
That suggests to me that srand(42) should produce identical results whenever it is called.
I can't find anything in the docs that indicate there have been changes to srand - grepping 5.20.0 perldelta for srand produced no hits.

However, there *is* mention (in perldelta) of changes to rand with 5.20, and I guess that if the rand implementation has changed then the same seed will no longer yield same results.
I do think that the breakage of srand($seed) between 5.20 and earlier perls should have been spelled out in the srand documentation ... probably worth a bug report from someone who cares.

Cheers,
Rob

Replies are listed 'Best First'.
Re^7: Late PM, 12/24/2014 & all year long
by BrowserUk (Patriarch) on Dec 30, 2014 at 11:31 UTC
    I do think that the breakage of srand($seed) between 5.20 and earlier perls should have been spelled out in the srand documentation ... probably worth a bug report from someone who cares.

    As documented in the 5.20 delta:

    rand now uses a consistent random number generator Previously perl would use a platform specific random number generator, varying between the libc rand(), random() or drand48(). This meant that the quality of perl's random numbers would vary from platform to platform, from the 15 bits of rand() on Windows to 48-bits on POSIX platforms such as Linux with drand48(). Perl now uses its own internal drand48() implementation on all platforms. This does not make perl's rand cryptographically secure.

    The effect of srand was platform specific. Ie different between Windows & *nix. And that is the cause of the failures for the obfu.

    From 5.20 on, that problem goes away because of the built-in rand/srand rather inheriting them from the platform C compiler implementation.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      Ie different between Windows & *nix. And that is the cause of the failures for the obfu

      Yes, I think that's the cause of most of the failures - but not the one that Athanasius experienced with Strawberry Perl. My Strawberry Perl 5.20.0 produces the same as Athanasius got:
      C:\_32\strawberry5.20.0>perl -e "srand 42; print sort {4-rand 9} split + //, 'ts aroMrhirsae C tll!!ym';" l ttyaMeos arrCsrihm!!l
      But when I switch to 5.18.2 it all works as intended:
      C:\_32\strawberry5.18.2>perl -e "srand 42; print sort {4-rand 9} split + //, 'ts aroMrhirsae C tll!!ym';" Merry Christmas to all!! C:\_32\strawberry5.18.2>
      And it also works as expected for me all the way back to 5.8.8 (which is as far back as I go).

      From 5.20 on, that problem goes away because of the built-in rand/srand rather inheriting them from the platform C compiler implementation.

      Agreed, and it was worth doing for that very reason.
      I just think they should have mentioned, in the srand documentation, that srand(42) would produce different results (on Windows) for 5.20.0 as compared to earlier perl versions - but the srand documentation (as it stands) suggests to me that no such change is to be expected.

      Cheers,
      Rob
        I just think they should have mentioned, in the srand documentation, that srand(42) would produce different results (on Windows) for 5.20.0 as compared to earlier perl versions - but the srand documentation (as it stands) suggests to me that no such change is to be expected.

        I think that it is inherent that if the implementation of rand changes, then the effect of srand( N ) will also change. It couldn't be otherwise.

        Effectively, all PRNG produce a fixed sequence of numbers of some length and then wrap-around to the beginning and produce the same sequence again.

        All srand does it pick a fixed offset into the sequence from which to start.

        Supplying the same offset to two different PRNG sequences will (usually) result in a different first value. And the subsequent sequence of values will definitely be different.


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.