Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
As we have many Sorting algorithms,I wanted to select the proper sorting algorithm for my case.
For Ex:Insertion sort is best for Small case of numbers ,whereas Merge sort is best suited for Large case of numbers.
I dont know what is that small range of numbers means .i.e 1-100 or 1-1000 or so.
Probably what is the best case for sorting a list of numbers where the same set of numbers are present present repeatedly.I am planning to store it in a hash and then store the elements accordingly .
Whether doing in through hash is a better way or Using some sorting algorithm is the best way
But as here it contains the same data again and again
If you add some elements to already sorted array(list), then you have only small number of inversions. In this case insertion sort will work rather fast.
Alternatives - natural merge sort or TimSort(if implementation is available for your language) - these ones will behave good in all cases, including unsorted arrays.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
This post was edited and submitted for review 1 year ago and failed to reopen the post:
Original close reason(s) were not resolved
Improve this question
I need to program an application in Java language that has a pre-defined number of categories,
but the exact items in each category are unknown. Which one of the following data
structures I would use and why? Array, singly linked list, or doubly linked list
I'd go with a map that contains a List, the implementation is irrelevant.
Map<Category, Collection<Item>> categoryMap
If the categories are ordered, use a TreeMap
If they're not ordered, use a Hashmap
If the items are known to be unique I'd have the Collection be a Hashset;
If the items are unique and ordered, I'd use a Treeset;
If they're non-unique, I'd use an ArrayList.
I see no reason to use a LinkedList of any variety if the number of entries are known. The reason to use LinkedLists is if there's to be many insertion/removal operations.
In almost all use cases an ArrayList is the superior implementation to use. The only real downside to an ArrayList is if it's gets modified often, especially added to as it uses a "double up" method for resizing the internal array. Basically, if it needs more room, it doubles the size of the existing array and then copy the items from the old array into the new array. That can cause memory issue for large lists, but you'd need to be dealing with thousands of entries.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I have a question. I'm currently taking a class on Object Oriented Programming with Data Structures, and there was a question on a quiz that I apparently got wrong.
"Which of the following search algorithms is the fastest at sorting a 1-D array which is already mostly sorted?"
The answers listed were: Quick Sort, Insertion Sort, Merge Sort, Selection Sort
I wasn't sure how large the lists were, so I chose Insertion sort because I know that O(n) would be the best case time complexity for a mostly sorted list that wasn't too large. The correct answer for it was Merge sort. I decided to run some tests and, for a mostly sorted list of 500, the results showed that Insertion sort was the fastest. However, I know that Merge sort would win if the list were larger. When I asked why Insertion sort would not also be an answer, I received replies stating that I'm always to assume that the lists in these questions are very large lists and to always assume worst case. No one could provide me any documentation on that answer, so that's why I'm here. When asked a question like this, am I to always assume the worst case and that the list will be large?
I think in this particular case it has to be said that the quiz question is rather ill-defined. I mean what is mostly sorted. The worst case for merge sort is O(nlog(n)) so unless mostly sorted means < log(n) is sorted, then merge wins. Otherwise I think you would be correct. The size of the list doesn't really matter.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have written a code for both counting sort and quicksort in the Java language to sort integers. Both the codes work fine for smaller inputs, but when I gave the size of the array of the order of 100,000, the quicksort stops working whereas the counting sort sorted it correctly. So can I say that it is better to use counting sort over quicksort when the size of the unsorted array is very large? I am using Eclipse IDE Oxygen.3a Release (4.7.3a).Thanks in advance.
Counting sort has better time complexity but worse space complexity. So if you have very large sets it really depends on what is more important to you memory consumption or CPU consumption.
It should be noted that while counting sort is computationally superior it only applies to sorting small integer values. So while it is superior it is not always a valid replacement for Quicksort. So it is not accurate to claim that it replaces Quicksort as an option entirely.
See the following link for details: http://bigocheatsheet.com/
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Right now I have implemented following algorithm in java for determining all possible candidate keys which is working fine. The link is below:-
http://shubhamshoundic.blogspot.com/2012/08/an-algorithm-to-find-all-possible.html
But in worst case, i.e., if all attributes are present on both sides of the FD (as in case M defined in above link), the number of FD which can be handled are reduced to 12 or 13 .
Reason is limited heap space in java. Following error is being thrown:-
OutOfMemoryError
My request is to help me is in implementing such algorithm which will have simpler complexity (Right now its exponential) to improve the number of FD being handled to at least 20.
Should I try to calculate it using multiprocessing or should I shift to another language rather than java.
It is known from 1978, and presented in all good books on databases, that the problem of finding all the keys requires an algorithm which has an exponential complexity in the worst case (see for instance: Lucchesi, C. and Osborn, S. (1978). Candidate keys for relations. Journal of Computer and System Sciences, 17(2):270–280). Moreover, the problem of finding if an attribute is prime is NP Complete.
This is due to the fact that the number of possible keys is itself exponential with the number of attributes or factorial with the number of functional dependencies.
So, it is impossible to find an algorithm polynomial with the number of attributes or of the functional dependencies.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
consider the following Strings:
he llo
goodbye
hello
= (goodbye)
(he)(llo)
good bye
helium
I'm trying to sort these in such a way that similar words comes together, I know
alphanumerical sorting is not an option
removing special chars ",-_ and etc then comparing is certainly helpful but results won't be as good as I hope for.
NOTE :
there might be few different desired ouput for this, one of which is :
DESIRED OUTPUT:
hello
he llo
(he)(llo)
helium
goodbye
good bye
= (goodbye)
so my question is that if there is a java package that compares strings and ultimately sort them based on it .
I've heard of terms such as n-gram and skip-gram but didn't quite understand them. I'm not even sure if they can be useful for me at all.
UPDATE:
finding similarities is certainly part of my question but the main problem is the sorting part.
Here's one possible approach.
Calculate the edit distance/Levenshtein distance between each pair of strings and then you use view the strings as a complete graph where the edge weights come from the edit distance. Choose a threshold for those weights and remove all the weights that to high. Then find the cliques in this graph. If your threshold is fairly low perhaps even finding connected components would be an option.
Note:
Perhaps it would be better to substitute some edit distance with one of the similarity measures in the link that #dognose posted.
Also, note that finding cliques will be very slow if you have a large numbers of strings