Shuffling

This is a bit of a tongue-in-cheek suggestion, but I’ve actually used it a few times.

As many posters have pointed out, choosing a good seed value can make all the difference. My method is called Pr0nSeed. I select an image from a library of photos I’ve taken. (I’ve yet to run out, but I could shuffle them based on (say) file-size and dimensions and a random component, and then cycle through the newly shuffled list).

Then I use the built-in RNG to select a pixel (in a variant of this, you could simply cycle through each pixel in sequence, but that depends on your image – continuous tone gradients can be predictable). Then I build a seed using the R, G, and B values of the pixel that results.

Obviously the type of images you use will affect the quality of your seed – for one thing, the less compression and the less post-processing, the better.

You could even generate the “random” number directly from the RGB values without using the RNG to generate X and Y values, just by iterating through the pixels.

Another thought to improve quality (i.e. unpredictability): If you have a library of images you can (in a pre-process) run through them and toss out those that don’t meet a certain threshold for the number of distinct colors (i.e. an overexposed picture of a white piece of paper would be fairly useless).

Also, you could pick R, G, and B values from separate pixels, not the same one.

This seeding algorithm relies on the idea that you own a collection of images that no-one else has access to. If you take your own pictures (particularly high-res ones) and secure them decently, you can rely (as far as I can see) on your sequence being fairly unpredictable.

I called it Pr0nSeed because when I originally came up with I needed a large library of images, so I used my, uh, downloaded adult-themed images :slight_smile: Now I use a collection of photos I’ve taken myself which are far more boring but contain less continuous-tone imagery – stuff like sand, gravel, trees, etc.

Ultimately this algorithm uses the system RNG (or a library RNG) simply as an indexer into a large array (the image) of unpredictable numbers. The current picture is changed every “x” calls to Random(), where “x” represents a tradeoff between possibly repeating values (due to a poor RNG or an image with too few distinct colors) and performance.

Not being a mathematician (or, indeed, even having a CS qualification of any kind) I’d be interested in comments on potential flaws in this approach (I’m sure there are many).

I hope this comment will bubble up.

Post has a lot of good details, but there is a problem with the second code in C#.

var cards = Enumerable.Range(0, 51);
var shuffledcards = cards.OrderBy(a => Guid.NewGuid());

There are two problems with it covered by Eric Lippert:

Do not use a random function as a comparator and feed that to a sorting algorithm. Sort algorithms are permitted to do anything they please if the comparator is bad, including crashing, and including producing non-random results. As Microsoft recently found out, it is extremely embarrassing to get a simple algorithm like this wrong.

Do not sort on a "random" GUID as your key. GUIDs are guaranteed to be unique. They are not guaranteed to be randomly ordered. It is perfectly legal for an implementation to spit out consecutive GUIDs.

Source: http://stackoverflow.com/questions/5519385/calling-a-list-of-methods-in-a-random-sequence/5519621#5519621

Kind Regards,
Lukas M

Funny story. I had to create an algorithm in C# that would shuffle 2 lists in a database that we had yet to get from the client. After much head-banging and learning about RNG, i discovered the total length of our 2 lists we needed to shuffle. 4 and 26. Hence 4 factorial and 26 factorial.