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
Campbell Ritchie
Marshal
Posts: 57444
175
posted 9 years ago
[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.
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: 57444
175
posted 9 years ago
Regarding noduplicates: 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: 57444
175
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.
[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 pregenerate 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 fillthesetthenremoveitems 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 pregenerate 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 fillthesetthenremoveitems 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: 57444
175
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 pseudorandom), 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 foreach 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 foreach 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
[Campbell]: If the input is random (and java.util.Random is described as pseudorandom), 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 pseudorandom; 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.
Hm, I didn't really follow this part. I understand that Random is pseudorandom; 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.
Tell me how it all turns out. Here is a tiny ad:
The WEB SERVICES and JAXRS Course
https://coderanch.com/t/690789/WEBSERVICESJAXRS
