2 Answers
2

Lists are immutable, and there's often a log n price to pay for working with immutable data. If you're willing to pay this cost, there's an obvious n log n approach: tag each list element with a random value, sort based on random value, remove random values. This is the way I shuffle lists in my production code.

Yes, I thought so too. The interesting thing is that this question popped up to me as I am going to write quicksort. for quicksort, I have shuffle the list first, then do the partition, etc. In this case, how do I sort the random values in your code?
–
Jackson TaleFeb 26 '13 at 17:44

It seems the deviations arise when tags are equal. With 63 bits of tag this is a small deviation. (I read that message from Oleg when it came out. He is awesome.)
–
Jeffrey ScofieldFeb 26 '13 at 17:49

@sepp2k I think the negative point of the attach_value-then-sort algorithm that message was talking about can be easily fixed by that while sorting the attached values, if two values are equal, then generate another 0|1 to decide who comes in front, i.e., we don't want stable sort. Am I correct? how anyway, that message is correct, if stable sort is used
–
Jackson TaleFeb 26 '13 at 18:03

have two auxiliary lists A and B, iter through your original list L and push each element randomly (with probability 1/2) in front of A or B.

L := List.rev A @ List.rev B (this can be tail recursive with a custom List.rev).

repeat k times.

According to "Mathematical developments from the analysis of riffle shuffling, by Persi Diaconis, 2002", choose k = 3/2 log_2(n) + c. Indeed, the total variation distance between uniformity and the result falls exponentially fast to 0: it is approximately halved each time you increment c. You could choose c=10.

Space O(1) (if you destroy L), time O(n log n). But there are O(n log n) calls to the random generator, while Jeffrey Scofield's solution only needs O(n) random bits, but Θ(n) space.