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

Uwe Dauernheim <>
Thu Jul 19 10:21:56 CEST 2012

@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}).
2> random:uniform().    
3> random:uniform().
4> random:uniform().

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

1> random:seed({1,2,3}).
2> random:uniform().    
3> random:uniform().
4> random:uniform().

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

More information about the erlang-questions mailing list