Re^8: Late PM, 12/24/2014 & all year long

[syphilis]

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

[BrowserUk]

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.

[syphilis]

I think that it is inherent that if the implementation of rand changes, then the effect of srand( N ) will also change

I agree - and I thought I said so in my initial post:

However, there *is* mention (in perldelta) of changes to rand with 5.2
+0, and I guess that if the rand implementation has changed then the s
+ame seed will no longer yield same results.

(Admittedly, I probably wasn't being as clear or emphatic as you ;-)

You perhaps knew this (though I've only just realized it) but on my nix boxes there is *no* change in rand between 5.20.0 and earlier perl versions. It seems the change in rand was merely that of bringing Windows into line with nix - though I don't assume that Windows is the *only* system thus affected.

I still raise my eyebrows at the srand documentation I quoted earlier - the "predictable behaviour" mentioned there might still apply to nix across modern versions of perl, but that is not so for Windows (and some other systems, no doubt).
If it says that srand($seed) produces "predictable behaviour", with no caveats, then I think people are entitled to think that the behaviour will be predictable.

Thankfully, I don't care enough to pursue the matter with p5p.

Cheers,
Rob

[BrowserUk]

It seems the change in rand was merely that of bringing Windows into line with nix -

That's cool. (Though personally I think I would have preferred they'd used the 64-bit Mersenne Twister algorithm everywhere. )

I still raise my eyebrows at the srand documentation I quoted earlier - the "predictable behaviour" mentioned there might still apply to nix across modern versions of perl, but that is not so for Windows (and some other systems, no doubt). If it says that srand($seed) produces "predictable behaviour", with no caveats, then I think people are entitled to think that the behaviour will be predictable.

Agreed.