Quote Originally Posted by jemidiah
The Knuth shuffle described shouldn't be tough to implement if you wanted to go that route, and it would use just as much memory as your current method does initially. It would also eliminate the need to resize your array.

Or, you could optimize your method a bit by using a "deleted" flag/marker (maybe setting the array element to 0) during the first half (or so) of the number generation, and then by resizing the array during the rest of the number generation. Since it would probably take the longest to resize at the start of the process when the array is incredibly long, this would seem to be much more efficient. Also, your chance of having to redo your random choice using the marker system (that is, you'd have to choose another index if the one you chose was marked "deleted") would increase substantially near the end of the number generation.

Cutting out those two effects would probably make the entire routine much faster, though it looks like the Knuth shuffle would be easier to implement than these optimizations.

Good luck!
Out of a technicality, there's no real "array" going on... it's a list. I just loop through from the lower to upper bounds, adding every number to a list. I then pick a random member of the list, add that to the final list, and remove it from the list of available numbers, so each number can only be chosen once, and there's no looping to verify that a number is indeed unique. If it's in the first list, it hasn't been chosen yet... which seems to work very well indeed. I'll look into the other method for speed determinations, though.