Yes, thank you for your time. I am running this to create random numbers but about 5% of the time I get a duplicate. For my concept, I can have no duplicates or will this result in an extra button that says " you have a duplicate, please re-roll"?

Thank you and I apologize if the code dose'nt show up correctly, my preview is not showing it with the format.

I fixed up the code formatting for you. We have a page called UseCodeTags (<-- click) that shows you how to use those.

If you do not want duplicates, ever, then it's not truly random is it? If you're selecting at random from a set range, then for each new 'roll' the result becomes more and more deterministic until the last roll when you can guarantee the outcome.

Perhaps if you want to select at random a number from a predefined set, you could have that set in a collection, shuffle the collection, and then pop one off the top, thus making it unavailable for subsequent selections. This approach, however, will not scale very well for very large sets as memory consumption will become a problem.

After re-reading your post I get it I think. if I never go above the set high of 59 then the memory problem shouldn't be an issue. I still am not sure what you mean by being "truly random" though. What about java makes "random" not really random? Does it have something to do with the left over math?

No, I'm talking to myself now. Integer is a whole number so where does the "not so random come from? I really suck at math lol.

Your criteria, as I understand it, is to have a bunch of random, but unique, numbers between 1 and 59. Right?

It's the fact that you need uniqueness that reduces the randomness of your algorithm. Let's simplify the example so we can visualise it nicely in our brains:

Say we want to select random, but unique, numbers between 0 and 1.

First selection has a probability of 1/2 (50%), you have equal chance of getting 0 or 1.
Second selection has a probability of 1/1 (100%), you can guarantee the outcome. This is not a random selection.
Third selection. What now? There are no choices left.

Tim Driven Development

Campbell Ritchie

Marshal

Posts: 56546

172

posted 2 years ago

You don't call that random at all. I think it is called random selection from a diminishing population. Or something like that.

Forget about java. Say you have a bag with some kind of tokens in it. Each token has a single number written on it - say every integer from 1 - 59.

The question is - after I pull out a token to get a random number, do i put that token back in the bag before drawing the next, or do I set it aside?

If i replace the token, then each time I pull out a number, I have an equal chance (1-of-59) of getting any of the numbers 1-59. If I don't replace, it, then I have a ZERO percent chance of drawing a duplicate, and a slightly better chance (1-of-58) of getting a specific remaining number.

Further, the first method (select and replace) lets me keep pulling numbers forever. The second - pull and set aside - eventually I will run out of numbers, and will be unable to draw any more.

There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors

To put a different spin on it, say you had a dartboard and you randomly throw darts at it, say 59 times. Out of those 59 times, there is a good probability that you will hit the same number on the dartboard at least twice. you should expect the same kind of duplication in your program. If you want uniqueness, then the metaphor would be a deck of cards that you shuffle 7 times to randomize the order. As others have said, the more cards you turn over from this deck, the more certain you are of knowing what the next one you turn over will be, by process of elimination/deduction. However, if you have an unlimited number of decks which have been randomly shuffled, then you are back to the situation where you are going to get duplicates from this large randomized set of cards.

As for uniqueness reducing randomness as discussed above, I'm not sure that's right. As with the deck of cards, the randomness is determined by the shuffling algorithm. The randomness does not change just because the deck is gradually reduced. The probability of being able to correctly guess the next card does increase as you turn over more cards though but I don't see that it changes the randomness of the order of the cards -- that was already established in the beginning when you shuffled the deck.

Chris Pow wrote: Ok, thank you all. I get it. It's not really random until I make the number that is generated in the console, lets say 1 not be available again after it is "picked".

Hmmm, it may be that you've resolved your issue but with that statement, I'm not sure that you got it. Randomness and uniqueness are two separate things. You can randomize a collection of things. You can also make sure that your collection is made up of unique things, or not. But just because a collection does not have uniqueness that doesn't mean it is any less randomized than a collection that does have uniqueness, assuming you are randomizing both groups the same way.

Think about it, if I had a group of 10 people named John and another group of 10 people each with different names, and I randomly selected a person from each group, would I be selecting less randomly from the the first group than from the second group? The fact that I will pick a person named John from the first group every time is irrespective of the randomness with which I pick the person, right?