test/random.jl: segregate deterministic tests at the end

[rfourquet]

See #8313 for context and in particular #8313 (comment) for the rationale of this change.
In short, the first test in "test/random.jl", which needed to seed the global RNG with a deterministic value (srand(0)), was leaking determinism on all the tests coming after it.

[ivarne]

How would you get the RANDOM_SEED.txt file from a failed travis run? We also need a way to rerun the tests with the failing seed.

One solution to the first issue might be to create a @test_random macro that prints Base.Random.RANDOM_SEED on test failure and otherwise behaves like @test.

[StefanKarpinski]

Printing the RNG state right before the failed test would be even better. That way you can reproduce the failure without running any other tests.

[ivarne]

That would require a method to get and set the internal RNG state. Do we even want that to be part of the API? Tests also often depends on variables declared at an earlier point of the test file, so you would have to run the other tests as well.

[StefanKarpinski]

Well, I would want it. Not sure how many RNGs allow it. Setting up local variables is possible without running everything before, especially now that we print better info in failed tests.

[andreasnoack]

The state is stored as a Vector{Int32} in a DSFMT_state type and therefore it is fairly easy to get and set. However, it is important that you don't use a setstate! method as a seeding mechanism because the Mersenne-Twister can work poorly for some states. Therefore the library has specialized seeding functions that chooses a good state from a Uint32 seed.

I agree, that it would be useful to have the state printed for failing tests.

[rfourquet]

I of course didn't think of Travis...
The random.jl tests are not that long to run, so it's not a too big problem if they have to be rerun when there is a failure, until a @test_random macro is implemented (I mean that the person trying to debug can then e.g. manually insert prints statements to get the RNG state just before the failed test).
Would you suggest that I remove the writing to RANDOM_SEED.txt from this commit?

[ivarne]

Maybe something like?

srand() #Reseed the RNG with entropy from the OS
seed = rand(Uint)
#seed = 
println("Running random tests with seed\nseed = 0x",hex(seed))
srand(seed)

[rfourquet]

I'm not sure why you would like seeding with rand(Uint)... is it so to be able to print only an Uint instead of RANDOM_SEED which is an array of four Uint32 ?

[ivarne]

It was for convenience and shorter printing. If you think there are any benefit in using RANDOM_SEED directly, please do that.

[rfourquet]

I would then prefer to print RANDOM_SEED as an Uint128. So do you suggest I update this PR to print to the screen instead of to the file?

[ivarne]

Yes, for Travis and bug reports, it seems better to print to STDOUT. Uint128 seems like a good idea.

[rfourquet]

Done.

[ViralBShah]

What's the final word here?

[rfourquet]

I think that there the problem is still there (most tests don't "require" the srand(0) at the beginning of the file, and would then be more useful if run with different seeds each time), but this PR may not be the best solution now that the rand API has been extended. I need to think more about it, but I would suggest that the global RNG is not re-seeded (except to test srand(seed), but then the original seed would be set back after the test), and that tests using srand use also an explicit MersenneTwister instance. I will make an updated PR soon.

[rfourquet]

Superseeded by #16924 and #16940 (pun intended).