I'm curious how an insertion sort would be for strings. I know how to do with numbers.
Could someone show me an implementation?
No, it's not for homework.
Thanks.
The sorting algorithm is pretty much the same no matter what you're sorting. The only difference is that with Strings (or any type of Object) you need to use the compareTo method rather than simply if (a < b).
You should be able to adapt an insertion sort for numbers to Strings by using String.compareTo to determine whether Strings are 'less than' or 'greater than' each other.
Additionally, a quick google search turns up several implementations, like this one which uses the general Comparable interface (which String implements).
Related
I am currently a computer science major and am taking a course in advanced java programming. My question today is if you have two identical lists, lets call them list1 and list2, and you invoke Collections.sort(list1) and Collections.sort(list2), is it possible for these two lists to be different after invoking this? My textbook says that it is possible, while my professor says it isn't. Can someone please clarify this for me?
If we consider the obvious case such as sorting List<Integer>, then no it's not possible. If you're sorting two identical lists, they should be properly sorted of course.
However since Collections.sort() requires that the objects being sorted are Comparable, you can always implement Comparable poorly. For example you could have compareTo() return a random value (or the time of day, or anything not related to the object actually being sorted), and you wouldn't have any idea how they would be sorted.
Collections.sort() can notice if compareTo() is implemented wrong and will throw an exception saying Comparison method violates its general contract!. However it's not 100% guaranteed to notice this, so technically it is possible to have 2 identical collections sorted in different ways.
As equality is defined by Object.equals(), but comparison is defined by Comparable.compareTo() or Comparator.compare(), like the javadoc says:
It is strongly recommended (though not required) that natural
orderings be consistent with equals.
Otherwise it is possible that equal elements are sorted differently.
For a Java assignment I have to sort by length an ArrayList<String> using the Comparable interface.
What I have done, and it works, is to create a custom object in a class that implements Comparableand set the CompareTo() to use length.
It's ok and it works.
I was just wondering if there is an easier way.
I know that String in Java already implements Comparable interface.
But the natural order is lexicographic or alphabetic, not by length.
I have no idea how I can implement a different CompareTo() for instances of the class String without having to create my object.
Is there a way?
Or am I missing the logic?
(I cannot use Comparator, I have to use the Comparable interface.)
I'm getting frustrated with institutions that shoehorn their curriculum into ridiculous and entirely unrealistic constraints.
In practice, you are going to be using a Comparator<String> which allows you the flexibility to use lambdas to sort the results. It's also incredibly terse, too.
On principle, what you've described is the only other logical approach. The only way you could practically solve this is to create your own class that encapsulates the String instance that you want, and sort that.
It sounds like your wrapper object is the simplest way to meet the silly requirement. Just write a method that compares the lengths of the contained strings.
Possible Duplicate of
When should a class be Comparable and/or Comparator?
I understand the difference that is given in this link.
And also in the book that i am referring it is given that we can not use comparable when we need to sort the objects on the basis of more than one fields.
My Question:
I just want an example where we could not possibly use comparable and have to go for comparator in order to compare and please also show that with comparable why can't we compare on two different fields of object.
If you find this question as duplicate please provide link,, i have searched many questions but none has the example that i wanted.
If a class implements Comparable, this defines what is usually considered the natural ordering of it elements. In some cases this is the only ordering that may make sense, in other cases it might be the most widely used ordering. If you look for example at numbers, there is probably only one (total) ordering that makes sense (except maybe for taking the reverse). As others already have pointed out, their are other objects that have other useful orderings. What makes the primary ordering (or if there is even one) depends on your application. If you manage persons with adresses in you application, phonebook sort order could be considered the natural order if this is the most widely used one and sorting by age could be a secondary. Slightly OT: Beware of cases where non equal objects are considered equal wrt to the ordering, this may yield problems with containers like OrderedList etc.
Comparing apples with each other will result in classes of equal apples, like red ones, green ones, old and fresh ones. That's OK as long as you only interested in a rather broad equality. But if you you are going to receive a paycheck you are very happy that you are identifiable within you equality class.
So compareto is good for sorting and clustering and equals/hashcode is got for identification.
Comparable is mostly used when there is a 'known' default sort order and the object or class that we are ordering is editable or owned by the developer making the change.
Comparator is suitable where the class or object being ordered is not owned by the developer making the change like a web service response. It is also preferred when the natural ordering doesn't fit the objective that needs to be accomplished.
I'm looking for a high performing data structure that behaves like a set and where the elements will always be an array of ints. The data structure only needs to fulfill this interface:
trait SetX {
def size:Int
def add(element:Array[Int])
def toArray:Array[Array[Int]]
}
The set should not contain duplicates and this could be achieved using Arrays.equals(int[] a, int[] a2) - i.e. the values of the arrays can't be the same.
Before creating it I have a rough idea of how many elements there will be but need resizing behaviour in case there are more than initially thought. The elements will always be the same length and I know what that is at the time of creation.
Of course I could use a Java HashSet (wrapping the arrays of course) but this is being used in a tight loop and it is too slow. I've looked at Trove and that works nicely (by using arrays but providing a TObjectHashingStrategy) but I was hoping that since my requirements are so specific there might be a quicker/more efficient way to do this.
Has anyone ever come across this or have an idea how I could accomplish this?
The trait above is Scala but I'm very happy with Java libs or code.
I should really say what I am doing. I am basically generating a large number of int arrays in a tight loop and at the end of it I just want to see the unique ones. I never have to remove elements from the set or anything else. Just add lots of int arrays to the set and at the end get out the unique ones.
Look at prefix trees. You can follow tree structure immediately during array generation. At the end of generation you will have an answer, if the generated array already is present in the set. Prefix tree would consume much less memory than an ordinary hash set.
If you are generating arrays and have a not very small chance of their equivalence, I suspect you are only taking numbers from a very limited range. It would simplify prefix tree implementation, too.
I'm sure that proper implementation would be faster than using any set implementation to keep solid arrays.
Downside of this solution is that you need to implement data structure yourself, because it would be integrated with the logic of code deeply.
If you want high performance then write your own:
Call it ArraySetInt.
Sets are usually either implemented as trees or hashtable.
If you want an array based set, this would slow down adding, maybe deleting, but will speed up iterating, low memory usage. etc.
First look how ArrayList is implemented.
remove the object and replace it with primitive int.
Then rename the add() to put() and change it to a type of sort by insertion. Use System.arraycopy() to insert. use Arrays.binsearch() to find the insert position and whether element already exist in one step.
With out knowing how much data or if you are doing more reads than write:
You should probably try (ie benchmark) the naive case of an array of arrays or array of special wrapped array (ie composite object with cached hashcode of array and the array). Generally on small data sets not much beats looping through an array (e.g. HashMap for an Enum can actually be slower than looping through).
If you have really large amount of data and your willing to make some compromises you might consider a bloom filter but it sounded like you don't have much data.
I'd go for some classic solution wrapping the array by a class providing faster equals and hashCode. The hashCode can be simply cached and equals can make use of it for quickly saying no in case of differing arrays.
I'd avoid Arrays.hashCode as it uses a stupid multiplier (31), which might lead to unneeded collisions. For a really fast equals you could make use of cryptography and say that two arrays are equals if and only if their SHA-1 are equal (you'd be the first to find a collision :D).
The ArrayWrapper rather simple and should be faster than using TObjectHashingStrategy as it never has to look at the data itself (fewer cache misses) and it has the fastest and best possible hashCode and equals.
You could also look for some CompactHashSet implementation as it can be faster due to better memory locality.
Here is the question:
Java sort based on two columns
But, can anyone explain how to do without using Comparator? In other words, How the comparator works internally for sorting multiple columns?
The sort method must have some way of finding out the relative order of pairs of rows. There are two supported ways of doing it using the normal sorts. Either use instances of a class that implements Comparable to represent rows, or use a Comparator.
If you don't want to do either of those, you would have to write your own, specialized, sort method. When it needs to compare two rows, it would look first at the higher priority column. If the rows differ in that column, that gives there order. If they are equal in that column, order them based on the second column.
That said, using a standard sort with either Comparable rows or a Comparator is much better than mixing up the sort logic and the comparison logic. Comparator is the more flexible way.