[erlang-questions] random:seed in R14, R15, ...

[Uwe Dauernheim]

@Rapsey For now I don't use the seeding and just give predefined fixture data, thanks.
@Samuel The problem is that given the same seed, you get different sequences:

$ PATH=/Users/uwe/dev/OTP/R14B03/bin erl
Erlang R14B03 ...

1> random:seed({1,2,3}).
undefined
2> random:uniform().    
1.9796325776202811e-4
3> random:uniform().
0.03381877363047378
4> random:uniform().
0.7775418875596665

$ PATH=/Users/uwe/dev/OTP/R15B01/bin erl
Erlang R15B01 ...

1> random:seed({1,2,3}).
undefined
2> random:uniform().    
0.05074967983013061
3> random:uniform().
0.6727957987976656
4> random:uniform().
0.16422626735554258

But it was my bad, the documentation actually now states that:

"The implementation changed in R15. Upgrading to R15 will break applications that expect a specific output for a given seed. The output is still deterministic number series, but different compared to releases older than R15."

On Jul 19, 2012, at 8:37 AM, Samuel wrote:

>> When writing test cases that exercise e.g. random:uniform/0 one wants to use random:seed/1 with a fixed seed for deterministic test results, but providing the seed function with a fixed value seems to result in a different sequence for R14 and R15 (maybe for older or upcoming release as well). This is a problem when distributing your code and you are not sure which release will be used.
>> 
>> What is the common solution for this?
> 
> For randomised tests cases I usually seed the generator with now() as
> I would do for normal pseudorandom usage, but I write the tests so
> that, if failed, I get the originating seed in the report. That means
> that the tests are not deterministic in general, but deterministic
> enough to replay if needed. In theory, that way you also increase the
> chances of finding a weird failing sequence by repeating the tests
> over and over.
> 
> It is similar to the strategy used by QuickCheck, which is a bit more
> advanced. There you don't control the seed either, but when something
> fails it reports the counterexample back, so you don't need the seed.
> 
> In general, if you are testing with pseudorandom generators is because
> you want to increase the coverage in a state space to big to be
> covered by just exploring the possible combinations, so you don't want
> to restrict your random sequences to just one.
> 
> Regards
> -- 
> Samuel