I'm having issues implementing a merge sort for a linked list, specifically, the merge part. I'm trying to sort a linked list containing strings and sort them alphabetically. However, my merge code sometimes skips pointers for some reason depending on the order of the original list. Currently I have:
public node merge(node left, node right){
node result = null;
if(left == null){
return right;
}else if(right == null){
return left;
}
// The data in the node are stored as strings.
// Compare if the string in the left node is less that
// the string in the right.
if(left.info.compareTo(right.info) < 0){
result = left;
result.next = merge(left.next, right);
}else{
result = right;
result.next = merge(left, right.next);
}
return result;
}
If I had a list that consisted of for example, f->t->c->t->h, my merge will return h->t->t, where pointers are being missed. However, if my list consisted of b->a->t->t->c then it correctly display it alphabetically, a->b->c->t->t, and no pointers are missed.
Any help is appreciated.
Thanks.
I think it is because you are holding the old pointers to left and right which may no longer be the heads to the sub-lists.
Change
mergeSort(left);
mergeSort(right);
to
left = mergeSort(left);
right = mergeSort(right);
This probably isn't worth an answer, but here it is.
It's a bit hard to figure out what's going on there, I for one didn't notice any glaring mistakes in the implementation (although I wouldn't use recursion on the merge part, it's simpler to implement it "iteratively").
In my opinion, you need to figure out what's going on step by step. If you know a couple of examples that work and that don't work (seems like you do), call each method directly with the expected input.
For instance, to figure out for sure if your split is working, create a list and pass it to split, print the result. Then call split on the two lists created by split, and so on, to make sure what's happening. (Now would be a good time to use JUnit, but you can do that by "hand" if you want to).
If split works fine for the several cases you can think of, then call the merge routine with two lists, and analyze the result in the same fashion. If that works ok, then add some debugging output to your merge.
Basically, test each part of your algorithm independently, it'll me a lot faster to figure out the problem then looking at it as a whole.
Sorry for writing up a wall of text and still not answering the question, but this is how I would try to solve the problem.
Related
I've been going through algorithm challenges on LeetCode and just completed "Remove Nth Node From End of List".
Many of the top answers claimed to have found a "one pass" solution and I've included a Java example below.
Please could someone explain why "while(n-->0) h2=h2.next;" doesn't count as an extra pass of the linked list and, therefore, make this a "two pass" solution?
public ListNode RemoveNthFromEnd(ListNode head, int n) {
ListNode h1=head, h2=head;
while(n-->0) h2=h2.next;
if(h2==null)return head.next; // The head need to be removed, do it.
h2=h2.next;
while(h2!=null){
h1=h1.next;
h2=h2.next;
}
h1.next=h1.next.next; // the one after the h1 need to be removed
return head;
}
I've looked in the comments to this and other solutions and couldn't find an answer. Equally, a general Google search didn't yield an explanation.
Thanks in advance.
No, it's not one-pass. One-pass is defined with respect to a sequential I/O mechanism (canonically a tape) and means that each piece of data is read at most once, in order. Analogizing the linked list to the tape here, this algorithm is not one-pass because in general, some node will have its next field read once by h2=h2.next (in either loop) and again by h1=h1.next in the second loop.
The algorithm is not single pass, but not because of the first loop.
The first loop performs a partial pass on n elements.
The second loop performs two simultaneous partial passes on l-n elements (that on h2 being complementary to that in the first loop). In total, 2l-n lookups of next fields.
A single-pass solution can be implemented with the help of a FIFO queue of length n, but this is "hiding" a partial pass.
I'm trying to make a binary tree based on a list. The list contains on index 0 the node, and on the index 1 and 2, the left and right child. On index 3 is another node and on index 4 and 5 is left and right child for the node on index 3, and so on. I've tried something like this
public static HNode buildHTree(List<HNode> list) {
HNode node = lista.get(0);
HNode left = lista.get(1);
HNode right = lista.get(2);
list.remove(0);
list.remove(0);
list.remove(0);
if(list.size() > 0)
return buildHTree(list);
return node;
}
but this doesn't work. Can some of you give me some hint or some help in making this.
The HNode class contains:
private Symbol value;
private HNode left, right;
and setters and getters for this.
Thank you very much
I want to tell me what is wrong with my thinking and how can change my code to achieve my goal.
One thing that is wrong with your thinking is that you seem to think that you can write "some code" and then "change" it to make it right. That is not a good way to program.
The better / right way is to:
understand the requirements before you start designing,
understand the algorithm before you start coding it,
when you run into a problem, read the code you have written and try to understand what it actually does. Then compare that with what you are trying to achieve; i.e. what you intended to write.
And don't be afraid of throwing away stuff and starting again.
Specific hints:
Should you be starting from a List<HNode>? Shouldn't it really be a List<Symbol>?
Shouldn't you be setting the left / right fields to put the nodes into a tree structure?
Do you know if the list is sorted?
Can someone please explain In Java how do you find middle element of a linked list in single pass?
I have googled it, but cannot seem to find a simple explanation on how to code it.
LinkedList<String> list = new LinkedList<>();
list.add("foo");
list.add("bar");
list.add("baz");
String middle = list.get(list.size()/2);
System.out.println(middle); // bar
The call to assign middle will pass through half of the list during the get call.
As pointed out in the comments, the middle is the worst place to operate on a LinkedList. Consider using another variation, such as ArrayList.
I think this is a sort of trick question that you see on lists of possible interview questions.
One solution would be to have two pointers to step through the list, one taking steps of two and one taking steps of one.
When the pointer that is taking two steps at a time reaches the end of the list, the one taking only one step will be halfway through.
I doubt that this practice is really useful though..
good luck!
Since it's a LinkedList, you won't be able to find out its size until after the first (and only) pass. To find the middle element, you need to know two things; what index is at the middle, and what is the value of the element at that index. Finding the middle index is easy--just make one pass through the list, keeping a counter of how many nodes there are. As you do this, you'll need to keep track of each element in a separate data structure, perhaps an ArrayList, since you're only allowed one pass through the LinkedList. Once you're done, half the counter to find the middle index, and return the ArrayList element at that index.
The pseudo code looks like this:
int count
ArrayList elements
for each node in LinkedList:
count++
elements.append(node)
middleIndex = count/2
middleElement = elements.getIndex(middleIndex)
return middleElement
Of course, you'll need to take care of the case where there isn't a single middle element.
Trying to perform a binary search on a sorted array of Book objects.
Its not working well, it returns the correct results for some of the objects, but not all.
I went through the loop on paper and it seems that a number can get missed out due to rounding #.5 upwards.
Any ideas how to make this work?
Book found = null;
/*
* Search at the center of the collection. If the reference is less than that,
* search in the upper half of the collection, else, search in the lower half.
* Loop until found else return null.
*/
int top = numberOfBooks()-1;
int bottom = 0;
int middle;
while (bottom <= top && found == null){
middle = (bottom + top)/2;
if (givenRef.compareTo(bookCollection.get(middle).getReference()) == 0) {
found = bookCollection.get(middle);
} else if (givenRef.compareTo(bookCollection.get(middle).getReference()) < 0){
bottom = middle + 1;
} else if (givenRef.compareTo(bookCollection.get(middle).getReference()) > 0){
top = middle - 1;
}
}
return found;
A couple suggestions for you:
there's no need to keep a Book variable. In your loop, just return the book when it's found, and at the end return null. And you can also remove the boolean check for the variable in the while condition.
the middle variable can be scoped inside the loop, no need to have it live longer.
you're doing bookCollection.get(middle).getReference() three times. Consider creating a variable and then using it.
the middle = (bottom + top)/2 is a classic mistake in binary search implementation algorithms. Even Joshua Bloch, who wrote the Java Collection classes, made that error (see this interesting blog post about it). Instead, use (bottom+top) >>> 1, to avoid integer overflow for very large values (you probably wouldn't encounter this error, but it's for the principle).
As for your actual problem statement, rounding would be downwards (integer division), not upwards. To troubleshoot the problem:
are you sure the numberOfBooks() method corresponds to the length of your collection?
are you sure the compareTo() method works as expected for the types you are using (in your code example we do not know what the getReference() return type is)
are you sure your collection is properly sorted according to getReference()?
and finally, are you sure that using givenRef.compareTo(bookCollection.get(middle).getReference()) < 0 is correct? In standard binary search implementations it would be reversed, e.g. bookCollection.get(middle).getReference().compareTo(givenRef) < 0. This might be what donroby mentions, not sure.
In any case, the way to find the error would be to try out different values and see for which the output is correct and for which it isn't, and thus infer what the problem is. You can also use your debugger to help you step through the algorithm, rather than using pencil and paper if you have to run many tests. Even better, as donroby said, write a unit test.
What about Collections.binarySearch()?
All of JRL's suggestions are right, but the actual fail is that your compares are reversed.
I didn't see this immediately myself, but replicating your code into a function (using strings instead of Books), writing a some simple Junit tests and then running them in the debugger made it really obvious.
Write unit tests!
I found the problem.
It turns out i was binary searching my bookCollection arrayList, and NOT the new sroted array i had created - sortedLib.
Silly mistake at my end, but thanks for the input and suggestions!
I'm looking for Java solution but any general answer is also OK.
Vector/ArrayList is O(1) for append and retrieve, but O(n) for prepend.
LinkedList (in Java implemented as doubly-linked-list) is O(1) for append and prepend, but O(n) for retrieval.
Deque (ArrayDeque) is O(1) for everything above but cannot retrieve element at arbitrary index.
In my mind a data structure that satisfy the requirement above has 2 growable list inside (one for prepend and one for append) and also stores an offset to determine where to get the element during retrieval.
You're looking for a double-ended queue. This is implemented the way you want in the C++ STL, which is you can index into it, but not in Java, as you noted. You could conceivably roll your own from standard components by using two arrays and storing where "zero" is. This could be wasteful of memory if you end up moving a long way from zero, but if you get too far you can rebase and allow the deque to crawl into a new array.
A more elegant solution that doesn't really require so much fanciness in managing two arrays is to impose a circular array onto a pre-allocated array. This would require implementing push_front, push_back, and the resizing of the array behind it, but the conditions for resizing and such would be much cleaner.
A deque (double-ended queue) may be implemented to provide all these operations in O(1) time, although not all implementations do. I've never used Java's ArrayDeque, so I thought you were joking about it not supporting random access, but you're absolutely right — as a "pure" deque, it only allows for easy access at the ends. I can see why, but that sure is annoying...
To me, the ideal way to implement an exceedingly fast deque is to use a circular buffer, especially since you are only interested in adding removing at the front and back. I'm not immediately aware of one in Java, but I've written one in Objective-C as part of an open-source framework. You're welcome to use the code, either as-is or as a pattern for implementing your own.
Here is a WebSVN portal to the code and the related documentation. The real meat is in the CHAbstractCircularBufferCollection.m file — look for the appendObject: and prependObject: methods. There is even a custom enumerator ("iterator" in Java) defined as well. The essential circular buffer logic is fairly trivial, and is captured in these 3 centralized #define macros:
#define transformIndex(index) ((headIndex + index) % arrayCapacity)
#define incrementIndex(index) (index = (index + 1) % arrayCapacity)
#define decrementIndex(index) (index = ((index) ? index : arrayCapacity) - 1)
As you can see in the objectAtIndex: method, all you do to access the Nth element in a deque is array[transformIndex(N)]. Note that I make tailIndex always point to one slot beyond the last stored element, so if headIndex == tailIndex, the array is full, or empty if the size is 0.
Hope that helps. My apologies for posting non-Java code, but the question author did say general answers were acceptable.
If you treat append to a Vector/ArrayList as O(1) - which it really isn't, but might be close enough in practice -
(EDIT - to clarify - append may be amortized constant time, that is - on average, the addition would be O(1), but might be quite a bit worse on spikes. Depending on context and the exact constants involved, this behavior can be deadly).
(This isn't Java, but some made-up language...).
One vector that will be called "Forward".
A second vector that will be called "Backwards".
When asked to append -
Forward.Append().
When asked to prepend -
Backwards.Append().
When asked to query -
if ( Index < Backwards.Size() )
{
return Backwards[ Backwards.Size() - Index - 1 ]
}
else
{
return Forward[ Index - Backwards.Size() ]
}
(and also check for the index being out of bounds).
Your idea might work. If those are the only operations you need to support, then two Vectors are all you need (call them Head and Tail). To prepend, you append to head, and to append, you append to tail. To access an element, if the index is less than head.Length, then return head[head.Length-1-index], otherwise return tail[index-head.Length]. All of these operations are clearly O(1).
Here is a data structure that supports O(1) append, prepend, first, last and size. We can easily add other methods from AbstractList<A> such as delete and update
import java.util.ArrayList;
public class FastAppendArrayList<A> {
private ArrayList<A> appends = new ArrayList<A>();
private ArrayList<A> prepends = new ArrayList<A>();
public void append(A element) {
appends.add(element);
}
public void prepend(A element) {
prepends.add(element);
}
public A get(int index) {
int i = prepends.size() - index;
return i >= 0 ? prepends.get(i) : appends.get(index + prepends.size());
}
public int size() {
return prepends.size() + appends.size();
}
public A first() {
return prepends.isEmpty() ? appends.get(0) : prepends.get(prepends.size());
}
public A last() {
return appends.isEmpty() ? prepends.get(0) : appends.get(prepends.size());
}
What you want is a double-ended queue (deque) like the STL has, since Java's ArrayDeque lacks get() for some reason. There were some good suggestions and links to implementations here:
Java equivalent of std::deque?