Weigthed shuffle

[froggeric]

Hi,

I just created a pull request in Github to modify the Order.shuffle function with a randomness factor (from 0.0 to 1.0). I am not too familiar with github, so I hope I got it right :) I could not do the same for the documentation part, as I do not speak russian (yet).

[Chimildic]

Can you show an example with simple numbers? I dont understand what is practical meaning with music contex. I think that users always wants to extreme random in order to haven't any familiar sequence.

[froggeric]

Example:

Order.shuffle( [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20], 0.15 )

// resulting array:
//  [9,1,2,3,4,5,6,7,15,8,10,19,11,13,12,14,16,20,17,18]

Here is an example where I find this useful, based on my experience as a DJ. Let's say I have a playlist alternating 4 different genre/style of music, a, b, c and d. The playlist would like this:
a,b,c,d,a,b,c,d,a,b,c,d,a,b,c,d,a,b,c,d

However, it is not just the alternation which is important, but also the progression of tracks. At the beginning I might want some well know songs that everybody likes to get everyone partying. Then toward the middle bring some new releases for people to discover, and at the end some rreally satisfying songs to leave a final good impression. Keeping the alternation as a,b,c,d throughout can make the playlist a bit too predictable and boring. Sometimes it is fine to have a couple of similar tracks following each other. With the previous example of the function call, a weighted shuffle would have stayed quite close to the sequence of tracks I chose, but would also have introduced a slight randomness in the alternation, as follow:

a,a,b,c,d,a,b,c,c,d,b,c,c,a,d,b,d,d,a,b

[froggeric]

Actually I noticed that the shuffle algorithm you used introduces bias, favouring the upper end of the array. I think it can be fixed relatively simply, at no extra computational cost. I will get back to you soon.