(moved from <#C0B9K7EP2|language-proposals>)

# stdlib

[littlelightcz]

(moved from #language-proposals)

[littlelightcz]

@ilya.gorbunov Hi Ilya, the first use case is purely mathematical/experimental, which means you want to pick a random element from a collection for some reason (whatever it might be) - it might be usefult especially in gaming algorithms etc.

[littlelightcz]

The second use case is when I have a list of expensive resources and I want to share them across multiple threads/coroutines. So I currently would like to do something like:

val resource = resources.random()
synchronized(resource) {
//some logic here
}

BTW if there is a better way or if there is a library for such multi-threaded resource sharing, your suggestions would be greatly appreciated 🙂

[spand]

Would you want it on Collection or List ?

[littlelightcz]

Well, I think it would be good if it was available almost for everything 🙂. Like List, Collection, Array, Set ... maybe even on sequences or iterables (but I am not sure about these ones). I use mostly just the List and rarely an Array, but it's hard to guess where other people might need this as well.

[Aregev2]

Maybe even Map, will choose a random entry, will return a Pair object with the key value combination

[orangy]

Gaming devs are using far more advanced algos than you could put into the stdlib

[littlelightcz]

@orangy Yeah, sorry for misinterpretation 🙂, my previous statement was kind of badly-told. What I meant was just that people in the gaming industry might want to pick random elements more often than others.

[Aregev2]

Well, its easy to do with java.util.Random, perhaps you will implement a random algorithm in pure Kotlin for multiplatform implementation

[orangy]

@littlelightcz nope, gaming industry needs far more sophisticated random functions. With some special properties.

[littlelightcz]

@orangy ah I see, now I understand 🙂

[littlelightcz]

@Aregev2 + the tricky part could be whether to maintain a single Random() instance or not (due to performance)

[Aregev2]

Yeah, didn't think about it

[Aregev2]

You basically create a new instance in every function call

[Aregev2]

So how can we create a single instance to all functions call, maybe with an extension property?

[littlelightcz]

... or just a static constant 🙂 anyway @orangy has changed my mind a bit about this. Maybe it should be placed in some dedicated library which would bring these extensions of randomness 🙂

[Aregev2]

There could be a kotlinx.random, for multiplatform ramdom generator implementation

[Aregev2]

Or a completely unofficial lib

[Aregev2]

But I don't really know how random works, it's something with shr/shl I think

[spand]

Well, the gates were kind of opened with MutableList<T>.shuffle()

[Aregev2]

Um then you can take list[0]

[spand]

Most issues are the same with that

[Aregev2]

But shuffle() works only for JVM

[spand]

Not since 1.2

[Aregev2]

Also for js and Native?

[spand]

https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/shuffle.html

[Aregev2]

But I checked it in KN, it gave me a compile error

[spand]

Hmm ok. I guess native does not have full support for the stdlib then

[littlelightcz]

If the List is big, then shuffle() could be quite expensive to call.

[ilya.gorbunov]

@littlelightcz
We're considering to introduce Random API to the common standard library. There will be no function to select a random element from a list for now, but it will be trivial to implement as an extension with that API.
See the KEEP: https://github.com/Kotlin/KEEP/issues/131

[gildor]

Really like proposed API for Random 👍
What about mentioned random element selection? It's of course trivial to implement, but maybe make sense to concider adding this extension to stdlib as part of Random proposal? Or this proposal exclusively about Random class?

[karelpeeters]

A bit off topic, but why is there some negativity around creating a new package and why would it need to be imported automatically? import statements are next to trival, no one ever reads them.

[ilya.gorbunov]

@gildor Makes sense but requires some additional design and discussion to evaluate how it would fit with the existing collection extensions

[ilya.gorbunov]

@karelpeeters Sure, it's not a question when authoring some third party library, but in the standard library it's about consistency with the other core API.

[littlelightcz]

@ilya.gorbunov thanks a lot, that sounds great! 🙂

[Aregev2]

Hope it will make it in the future 1.3, 😁😁

[Aregev2]

And maybe a function that takes a random element between the elements that match a certain predicte?

[karelpeeters]

.filter { ... }.choose()

[Aregev2]

Also Ok

[thomasnield]

Somewhat relevant, with all the stochastic optimization work I'm doing I'm putting together several flavors of random functionality in Kotlin-Statistics, including taking random elements from Sequences/Collections. I also have a weighted coin/dice which you'd likely use to discretely random select an enumerable with a bias towards each outcome.
https://github.com/thomasnield/kotlin-statistics/issues/26

[littlelightcz]

Regarding the second use case (expensive resource sharing), I've already started with some simple sketch of a library that should cover this. If it will work out well, maybe JetBrains team could also consider moving it to the standard coroutines library or implement their own version of a "resource pool" for concurrent usage. Let me know your opinions! 🙂 https://github.com/LittleLightCz/Krool