Answered by:
Non Repeating Random Numbers from 1 to 30
Question

Answers

That's called a random "permutation".
The cleanest way to do this is to have an array of the numbers from 1 to 30. Randomly take one of the N elements and move it to the end of the list, swap the one that was at the end into the place of the one you selected, then repeat considering only the first N1 elements. Each time you are putting a random element at the end of the list. If you do this N times, you will have ordered them randomly.
Here's an example: https://gist.github.com/uchida/1408990
 Proposed as answer by DotNet WangModerator Wednesday, September 16, 2015 2:34 AM
 Marked as answer by Herro wongMicrosoft contingent staff, Moderator Tuesday, September 22, 2015 1:55 AM
All replies

Just have a look at this:
http://www.dotnetperls.com/fisheryatesshuffle
Chris
Code Samples: Code Samples
Chrigas Blog: Chrigas Blog 
That's called a random "permutation".
The cleanest way to do this is to have an array of the numbers from 1 to 30. Randomly take one of the N elements and move it to the end of the list, swap the one that was at the end into the place of the one you selected, then repeat considering only the first N1 elements. Each time you are putting a random element at the end of the list. If you do this N times, you will have ordered them randomly.
Here's an example: https://gist.github.com/uchida/1408990
 Proposed as answer by DotNet WangModerator Wednesday, September 16, 2015 2:34 AM
 Marked as answer by Herro wongMicrosoft contingent staff, Moderator Tuesday, September 22, 2015 1:55 AM


Enumerable.Range(1, 30).ToList(). Select(r => new { id = r, guid = (Guid.NewGuid()) }). OrderBy(g => g.guid).ToList().ForEach( n => { Console.WriteLine(n.id); });
If number is not rather large, consider use the random feature of Guid to reach this.I've considered it, and although this produces a correct answer (because guids statistically never return duplicates), the performance of generating a guid is terrible compared to just picking random numbers. Also the sort of OrderBy is O(n log n) so it's vastly algorithmically inferior too. It just happens to be "cute" because it uses a relatively low amount of source code. But so does F(1,30), after you go implement F. So this is pointless in my opinion.
You're better off just using "order by random number" for performance, because the collisions of duplicate random numbers and stability of the sort skewing your distribution likely don't matter in most applications either.
I'd downvote this technique if I could, for the reasons I just mentioned.
The technique I suggested is called the FisherYates shuffle. Go find other implementations if you don't like the one I linked. It is algorithmically superior and more correct (statistically speaking). Guids don't have to be uniformly distributed or unpredictable.
See this discussion on the matter.