h

    holgerbrandl

    1 year ago
    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

    Shawn

    1 year ago
    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
    h

    holgerbrandl

    1 year ago
    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.
    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

    Derek Peirce

    1 year ago
    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.
    ilya.gorbunov

    ilya.gorbunov

    1 year ago
    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.
    h

    holgerbrandl

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