Originally posted by Edwin Dalorzo:
Use the java.util.Collections.frequency() method.
Originally posted by francis joby:
Dear Sir,
How to count duplicate entries in an ArrayList or Vector.
Regards joby
The Best way to predict your future is to create it - Every great individual common man
The Best way to predict your future is to create it - Every great individual common man
The Best way to predict your future is to create it - Every great individual common man
The Best way to predict your future is to create it - Every great individual common man
Originally posted by Ankur Sharma:
Well Dear Rathi,
What you expect output of your program, could you please let us know the explanations.
I think the output should be 6 but this program is giving 4 as output.
Originally posted by Edwin Dalorzo:
[QB]Do you realize that you just wrote 3 methods and around 60 lines of code just to determine if there is a duplicate item in a List?
I would still stick to the Sun implementation of the frequency method. It is just 18 lines of code and it does the work.
Originally posted by Robert Hill:
It is called learning how to program.
Originally posted by Edwin Dalorzo:
Do you realize that you just wrote 3 methods and around 60 lines of code just to determine if there is a duplicate item in a List?
I would still stick to the Sun implementation of the frequency method. It is just 18 lines of code and it does the work.
The Best way to predict your future is to create it - Every great individual common man
As we already mentioned we are not aware of JDk1.5 so I wrote my own method and same done by Rathi, I would also like to use Sun's method Frequency, but what if We don't have it. ???
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Stan James:
I very much like Ernest's use of the features already in the Collections. The OP wanted a count of duplicates ... I wondered if Set.addAll(someCollection) and checking the size difference wouldn't do it.
Originally posted by Ken Blair:
Unfortunately what "count" means seems ambiguous. Is it the number of duplicate entries for one item? The number of items that occur one or more times? The sum of all the entries that have a duplicate? Am I missing something here or are we tossing around solutions without any concrete requirements?
Originally posted by Ken Blair:
Unfortunately what "count" means seems ambiguous. Is it the number of duplicate entries for one item? The number of items that occur one or more times? The sum of all the entries that have a duplicate? Am I missing something here or are we tossing around solutions without any concrete requirements?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Edwin Dalorzo:
Go up in the posts, you will see that there is already one post offering a JDK1.4 implementation of the frequency algorithm. After all it is not a state secret. It is in the src.zip file that comes with the JDK.
Look, I know we programmers take a lot of pride of our code, and I apologize to all of you if somehow I offended anybody when I criticized one of the previously posted algorithms.
I am fairly new at Java, although I have accumulated good time as a programmer. Recently I read Effective Java (by Joshua Bloch) for the first time and I realized of all those algorithms I used to take pride of that were not so good at all compare to all those nifty ideas printed in the book. I and felt happy that somebody wrote that book to teach me how to do things better.
I probably couldn't tie Mr. Bloch shoes, and I may know less Java than many of you, but I do know we programmers like to complicate things more than necessary and we do love reinventing the wheel. We tend to be creative people after all. That's good. But we also have to develop the skill of simplicity and the ability to recognize that simple is better, is less cost, less money, less bugs, less maintenance, it is easy to read and easy to understand.
It simply appears, to my naked eye, that the posted algorithm was much more complicated than the ones previously posted. That�s all. My comments never had the intention to hurt any body's pride. I just want to say: why don't we try to make this simpler? What's the point in posting an algorithm that does the same than several others previously posted, but in a far more complicated way? Are we not misleading the person who posted the question?
That's something our bosses ask us as technologists every day? Why do you want to migrate to a more complicated more expensive database? Why do you want to remake a legacy system that is already working pretty well after years of IT evolution? And when they ask, we better have a good answer or we will get nothing of their money to buy those nice 21st century toys that everybody is deploying on their companies.
Again, I apologize if you found my words offensive.
[ October 05, 2006: Message edited by: Edwin Dalorzo ]
[ October 05, 2006: Message edited by: Edwin Dalorzo ]
Originally posted by Edwin Dalorzo:
Do you realize that you just wrote 3 methods and around 60 lines of code just to determine if there is a duplicate item in a List?
Originally posted by Edwin Dalorzo:
I did the following implementation of the Ernest's algorithm:
I run it on BeanShell and with a List of 10.000 items all of them, but two, containing new String("Obi-wan") and the other two, randomly located containing the new String("Anakin") and it took an average of:
120 ms with the duplicates check
170 ms without the duplicates check.
The same algorithm using the JDK frequency method and run on BeanShell several times takes an avergage of
341 ms with the duplicates check.
Like this:
I think Ernest has a good point.
Originally posted by Ernest Friedman-Hill:
Also, note that all the algorithms so far discussed have O(n^2) performance, which is really unacceptable for large lists. Here's a vastly faster (and vastly simpler and vastly shorter) O(N) algorithm:
Originally posted by rathi ji:
EFH, can you please post any good link which explain how to find performance (O(n^2) and O(n) etc) for any algorithm, in a simple language.
The Best way to predict your future is to create it - Every great individual common man
Originally posted by Ernest Friedman-Hill:
Also, note that all the algorithms so far discussed have O(n^2) performance, which is really unacceptable for large lists. Here's a vastly faster (and vastly simpler and vastly shorter) O(N) algorithm:
The folks who provided longer, slower versions might want to read this.
The Best way to predict your future is to create it - Every great individual common man
You ought to ventilate your mind and let the cobwebs out of it. Use this cup to catch the tiny ads:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|