Are there any plans to support determinism in the ...

# stdlib

[holgerbrandl]

Are there any plans to support determinism in the stdlib collection methods? E.g. by setting/reseeding the internal kotlin.random.Random.Default so that running listOf(1,2,3).shuffled() twice would give the same result. Controlling randomess is an important feature of every language that is intended for data-science (see https://www.w3schools.com/python/ref_random_seed.asp for python or https://www.rdocumentation.org/packages/simEd/versions/1.0.3/topics/set.seed for R

[Shawn]

I think the Kotlin developers know what the importance of being able to set the seed of an RNG is… you can always build your own RNG instances with a specified seed value (e.g. val random = Random(42)), and if “controlling randomness” is important in your application, you should make calls to RNG instances you control instead of relying on the Random.Default singleton

[holgerbrandl]

I'm aware of that. However, whenever we use some piece of code that includes library calls that use shuffled etc internally, we are loosing determinism.

[holgerbrandl]

That's why many languages (C++, c, rust, go, r, python, etc.) allow to set the seed systemwide I guess. It's imho more a flaw in java, that kotlin simply adopted.

[Derek Peirce]

shuffled() could be modified to take a Random as an argument, with a default of Random.Default. However, the library would then have to declare either that it commits to using the same sequence of random-value calls for all future updates, or that the same seed may lead to different results after an update to the stdlib.

[Derek Peirce]

This is the solution that the JVM uses: https://docs.oracle.com/javase/8/docs/api/java/util/Collections.html#shuffle-java.util.List-java.util.Random-

[ilya.gorbunov]

We allow controlling randomness of the stdlib functions by providing overloads that take an arbitrary Random instances including deterministic ones. We expect other libraries to follow this convention.
We're against providing any guaranties of determinism for Random.Default, for example being able to set its seed with some global method.
In fact, having such globally mutable seed in a concurrent environment doesn't make further random calls anymore predictable.

[holgerbrandl]

Thanks @ilya.gorbunov for this nice explanation. The concurrency argument makes a lot of sense indeed.