ayyappan Bas

Ranch Hand

Posts: 40

posted 9 years ago

class Ran

{public static void main(String[] args)

{

int l=0;

for(int i=0;i<=10;i++)

{

Random rand = new Random();

int n = 1 + rand.nextInt(9);

System.out.println(n);}}

but i need generate Random number without dublicate.hepl me

{public static void main(String[] args)

{

int l=0;

for(int i=0;i<=10;i++)

{

Random rand = new Random();

int n = 1 + rand.nextInt(9);

System.out.println(n);}}

but i need generate Random number without dublicate.hepl me

Thanks & Regards

Ayyappan

Michael Dunn

Ranch Hand

Posts: 4632

Campbell Ritchie

Marshal

Posts: 55751

163

Campbell Ritchie

Marshal

Posts: 55751

163

Mike Simmons

Ranch Hand

Posts: 3090

14

posted 9 years ago

Not at all. There are many types of random distributions. In this case, it's an even distribution across all numbers in a given range that have not previously been selected. That's fine - the fact that it's not an even distribution across all numbers in the range, period, does not mean it's not random. It just means it doesn't match one particular concept of a random distribution.

**[Campbell]: That is a contradiction in terms; randomness implies the possibility of duplicates.**

Not at all. There are many types of random distributions. In this case, it's an even distribution across all numbers in a given range that have not previously been selected. That's fine - the fact that it's not an even distribution across all numbers in the range, period, does not mean it's not random. It just means it doesn't match one particular concept of a random distribution.

Campbell Ritchie

Marshal

Posts: 55751

163

Don Solomon

Ranch Hand

Posts: 49

posted 9 years ago

Regarding no-duplicates: in that case, what you want is not a series of random numbers; what you want is a subset of the set of integers in a certain range. Therefore algorithms that produce the set and then shuffle it are a fine approach. Another way is to generate random numbers, storing them in a Set, until the Set is large enough; the Set, by its nature, will eliminate duplicates.

Regarding seetharaman venkatasamy's example: umm, huh?

Regarding seetharaman venkatasamy's example: umm, huh?

Campbell Ritchie

Marshal

Posts: 55751

163

Mike Simmons

Ranch Hand

Posts: 3090

14

posted 9 years ago

Purely random numbers, with no other stated constraints, would not be influenced by past behavior, true. This point is often heavily emphasized in introductory probability courses, to dislodge certain types of fallacious thinking that students may arrive with. However I see "no duplicates" in this thread not as a contradiction, but as a constraint. We're generating random numbers, subject to the constraint that there can be no duplicates. Certainly there is random behavior involved. And I hope no one would object if we used the term "random shuffle", right? My guess is Ayyappan is not a native English speaker, and yet his initial post seemed clear enough to me, since the "no duplicates" rule was stated up front.

You don't need to extract them, or pre-generate the set. You can just add new numbers to the set as you need to generate them. Each time you generate a new random number, test if it's already in the set. If it is, generate a new random number. Keep trying until you generate a random number that's not in the set.

This particular strategy works well initially, and more poorly as more members are added. It's a good choice if the total number of random numbers needed is small compared to the range of possible values. If you eventually need to generate

Right - it's not supposed to. A LinkedHashSet would do the job though. Not that you need to rely on insertion order behavior if you use the strategy I just described, but for the fill-the-set-then-remove-items strategy, it could be useful.

Incidentally, it's also possible to modify the shuffle() algorithm so that you don't shuffle the entire list at once. Instead you can just pick out one number at a time, randomly chosen from the remaining numbers, as needed. You still need to allocate an array big enough to store all the values, but as long as that's not more memory than you have available, I believe this strategy would be the fastest one possible, overall.

[ October 18, 2008: Message edited by: Mike Simmons ]

**[Campbell]: But if you put random numbers into a Set, and extract them, which order do you get them back in?**You don't need to extract them, or pre-generate the set. You can just add new numbers to the set as you need to generate them. Each time you generate a new random number, test if it's already in the set. If it is, generate a new random number. Keep trying until you generate a random number that's not in the set.

This particular strategy works well initially, and more poorly as more members are added. It's a good choice if the total number of random numbers needed is small compared to the range of possible values. If you eventually need to generate

*all*(or even most) of the possible values, then a shuffle is probably a better choice.**[Campbell]: Actually even HashSet doesn't seem to print in insertion order.**Right - it's not supposed to. A LinkedHashSet would do the job though. Not that you need to rely on insertion order behavior if you use the strategy I just described, but for the fill-the-set-then-remove-items strategy, it could be useful.

Incidentally, it's also possible to modify the shuffle() algorithm so that you don't shuffle the entire list at once. Instead you can just pick out one number at a time, randomly chosen from the remaining numbers, as needed. You still need to allocate an array big enough to store all the values, but as long as that's not more memory than you have available, I believe this strategy would be the fastest one possible, overall.

[ October 18, 2008: Message edited by: Mike Simmons ]

Campbell Ritchie

Marshal

Posts: 55751

163

posted 9 years ago

Took me a bit of time to see what you meant about not testing the numbers before inserting them, but I can see, yes, that would work nicely, and obviate the need to iterate the set at all. The array might, as you say, work fastest. If the input is random (and java.util.Random is described as pseudo-random), is there any need to shuffle the array? You won't notice a difference, but the array will preserve insertion order.

I altered the little program I posted earlier to try a LinkedHashSet, and only that maintains insertion order with the for-each loop. Obviously a TreeSet would have printed from smallest to largest.

I think we all agree about what the original poster wanted; it's just what you call it.

I altered the little program I posted earlier to try a LinkedHashSet, and only that maintains insertion order with the for-each loop. Obviously a TreeSet would have printed from smallest to largest.

I think we all agree about what the original poster wanted; it's just what you call it.

Mike Simmons

Ranch Hand

Posts: 3090

14

posted 9 years ago

Hm, I didn't really follow this part. I understand that Random is pseudo-random; I haven't been bothering to make that distinction, but it's true. Aside from that though I don't think I understand the scenario you're talking about. Which is odd since it seems to be based off what I said, but I think somewhere along the way we might have gotten different mental pictures.

I would say that it's not necessary to shuffle the entire array, but you need to at least shuffle parts as you go. When someone requests the first element of the array, shuffle just that first element by selecting another element at random (possibly the same element) and swapping the first element with that element. If that other element is also the same element, there's really nothing to do. When someone asks for the second element (index 1), swap with another element of index >= 1. When someone asks for the third element (index 2), swap with another element of index >=2. And so on.

Here's an implementation of what I was thinking of.

Agreed.

**[Campbell]: If the input is random (and java.util.Random is described as pseudo-random), is there any need to shuffle the array? You won't notice a difference, but the array will preserve insertion order.**

Hm, I didn't really follow this part. I understand that Random is pseudo-random; I haven't been bothering to make that distinction, but it's true. Aside from that though I don't think I understand the scenario you're talking about. Which is odd since it seems to be based off what I said, but I think somewhere along the way we might have gotten different mental pictures.

I would say that it's not necessary to shuffle the entire array, but you need to at least shuffle parts as you go. When someone requests the first element of the array, shuffle just that first element by selecting another element at random (possibly the same element) and swapping the first element with that element. If that other element is also the same element, there's really nothing to do. When someone asks for the second element (index 1), swap with another element of index >= 1. When someone asks for the third element (index 2), swap with another element of index >=2. And so on.

Here's an implementation of what I was thinking of.

**[Campbell]: I think we all agree about what the original poster wanted; it's just what you call it.**

Agreed.

Don't get me started about those stupid light bulbs. |