Friends, my professor covered Fibonacci heaps and gave a home work. The requirement is usually after a extract, we need to compress the root list by linking roots of same degree. We use array indexing to find another element of same degree. But now imagine that you don't have array indexing capabilities in your system. Implement extract using some data structures and additional pointers so that you can achieve same amortized time!!
I've broken my head over this but I'm not getting any ideas. Any clues or inputs???
Related
I have a node.js app with some arrays of 100K objects. Im doing .filter and .find and .include operations on the arrays but its taking a very long time to complete the operations, which is expected. Operations example is, I have two arrays with 100K items, i want to find the items that are in one array and not the other array, and then find the items where the id property is present in both arrays but other properties have changed. Im trying to think of ways to speed up the operations. Is it possible to pass these off to a C++ library within node? And if so, are there any libraries available to do so? Otherwise, anyone have any suggestions of speeding up performance on massive array operations in node?
I am looking to make a calendar and task list for any corresponding day - just like most of the calendar apps. Main purpose of this practice is to use data structures effectively.
I have thought of two approaches:
Use array for calender days and then make a linked list of tasks for corresponding days.
Use linked lists for both.
Another question is: Can i use trees in the above scenario?
Maybe i am totally wrong. Kindly guide me through, i am keen to learn.
Note: i will be using c++ as my tool but not STL.
Regards
Your first approach is more efficient in terms of time complexity as the tasks associated with any day can be accessed in constant time in an array. But the downside is that it will use much more space than a linked list.
If you use a linked list for the calendar days, you can add a new node for each day one at a time, rather than all at once (like in arrays). So the final space usage will be the same in both cases .
As far as trees are concerned, you can use Map - like Associative containers, which are usually implemented as Self-balancing BST, thus giving you decent efficiency, in terms of both, time (logarithmic) and space/memory (Proportional to the number of days stored in the calendar, but no space wastage, unlike arrays). You can associate a date to a linked list of strings in this case.
If I were you, I'd be using map<date,vector<string> > though.
I need a map-like data structure (in C++) for storing pairs (Key,T) with the following functionality:
You can insert new elements (Key,T) into the current structure
You can search for elements based on Key in the current structure
You can make a "snapshot" of the current version of the structure
You can switch to one of the versions of the structures which you took the snapshot of and continue all operations from there
Completely remove one of the versions
What I don't need
Element removal from the structure
Merging of different versions of the structure into one
Iteration over all (or some of) elements currently stored in the structure
In other words, you have some search structure that you can build up, but at any point you can jump in history, and expand the earlier/different version of the structure in a different way. Later on you may jump between those different versions.
In my project, Key and T are likely to be integers or pointer values, but not strings.
The primary objective is to reduce the time complexity; space consumption is secondary (but should be reasonable as well). To clarify, for me log(N)+log(S) (where N-number of elements, S-number of snapshots) would be enough, although faster is better :)
I have some rough idea how to implement it --- for example: being the structure a binary search tree, the insertion of a new element can clone the path from the root to the insertion location, while keeping the rest of the tree intact. Switching tree versions would be equivalent to picking a different version of the root node, for which some changes are simply not visible.
However, to make this custom tree efficient (e.g. self-balancing) it will require some additional effort and careful coding. Of course I can do it myself but perhaps there are already existing libraries to do exactly that?
Also, there is probably a proper name for this kind of data structure that I simply don't know, making my Google searches (or SO searches) total failures...
Thank you for your help!
I think what you are looking for is an immutable map. Functional (or functionally inspired) programming languages (such as Haskell or Scala) have immutable versions of most of the containers you'd find in the STL. Operations such as insertion/removal etc. then return a copy of the map (preserving the original) with the copy containing your requested modification. A lot of work has gone into designing the datastructures so that the copies are able to point to as much of the original datastructure as possible to reduce time and memory complexity of each operation.
You can find a lot more details in a book such as this one: http://www.amazon.co.uk/Purely-Functional-Structures-Chris-Okasaki/dp/0521663504.
While searching for some persistent search trees libraries I stumbled on this:
http://cg.scs.carleton.ca/~dana/pbst/
While it does not have the exact same functionality as needed, it seems pretty close to it. I will investigate.
(posting here, as someone may find it useful as well)
I've been struggling with this problem just like everyone else and I'm quite sure there has been more than enough posts to explain this problem. However in terms of understanding it fully, I wanted to share my thoughts and get more efficient solutions from all the great people in here related to Subset Sum problem.
I've searched it over the Internet and there is actually a lot sources but I'm really willing to re-implement an algorithm or finding my own in order to understand fully.
The key thing I'm struggling with is the efficiency considering the set size will be large. (I do not have a limit, just conceptually large). The two phases I'm trying to implement ideas on is finding two numbers that are equal to given integer T, finding three numbers and eventually K numbers. Some ideas I've though;
For the two integer part I'm thing basically sorting the array O(nlogn) and for each element in the array searching for its negative value. (i.e if the array element is 3 searching for -3). Maybe a hash table inclusion could be better, providing a O(1) indexing the element?
For the three or more integers I've found an amazing blog post;http://www.skorks.com/2011/02/algorithms-a-dropbox-challenge-and-dynamic-programming/. However even the author itself states that it is not applicable for large numbers.
So I was for 2 and 3 and more integers what ideas could be applied for the subset problem. I'm struggling with setting up a dynamic programming method that will be efficient for the large inputs as well.
That blog post you linked to looked pretty great, actually. This is, after all, an NP-complete problem...
But I bet you could speed it up even further. I haven't done any benchmarks, but I'm gonna guess that his use of a matrix is his single biggest time sink. First, it'll take a huge amount of memory for some really trivial inputs (For example: [-1000, 1000] will need 2001 columns! Good grief!), and then you're wasting a ton of cycles scanning through each row looking for "T"s, which are often gonna be pretty sparse.
So instead: Use a "set" data structure. That'll keep space and iteration time to a minimum,* but store values just as well: If it's in the set, it's a "T"; otherwise, it's an "F".
Hope that helps!
*: Of course, "minimum" doesn't necessarily = "small."
When is using a std::set more efficient (w.r.t. time) than using a std::vector along with make_heap/push_/pop_ for the priority queue in an A* operation? My guess is that if the vertices in the open list are small, using a vector is a better option. But does anyone have experience with this?
If i had to venture a guess? I'd guess that the vector version is probably a good choice because once it grows to a certain size, there won't be very many allocs.
But I don't like guessing. I prefer hard numbers. Try both, profile!
Use a priority queue. A binary heap based one is fine (like the vector based std priority queue). You can build the heap in O(n) time and all relevent operations take O(logn). In addition to that you can implement the decrease key operation which is useful for a*. It might be tricky to implement for the std queue however. The only way to do that with a set is to remove the element and reinsert it with a different priority.
Edit: you might want to look into using
std::make_heap
(and related functions). That way you get access to the vector and can easily implement decrease_key.
Edit 2: I see that you were intending on using make heap, so all you'd have to do is implement decrease key.
For A* search, I would go with a
std::vector-based priority queue.
However, the change in the
implementation from std::vector to another STL container should be
quite trivial, so I would experiment with different versions and see how
does it affect the algorithm
performance. In addition to stl::map, I would definitely try stl::deque.
If you're doing A* pathfinding work, check out the articles in AI Wisdom by Dan Higgins. In there is a description of how to get data structures fast. He mentions a "cheap list" which is like having a hot cache for recent nodes and avoiding a lot of the penalties for pathfinding data structures.
http://introgamedev.com/resource_aiwisdom.html
I don't think a vector based data structure for a priority queue for an A* search is a good idea because you're going to be constantly adding a single element somewhere in the list. If the fringe (I assume this is how you're doing it) is large and the element is to be added in the middle, this is highly inefficient.
When I implemented A* in Java a few weeks ago, I used the Java PriorityQueue which apparently is based on a priority heap, and that seems like a good way to do it. I recommend using set in C++.
EDIT: thanks Niki. I now understand how binary heaps are implemented (with an array), and I understand what you're actually asking in your question. I suspect a priority_queue is the best option, although (as Igor said) it wouldn't be hard to swap it over to a set to check the performance of that. I'm guessing there's a reason why priority queues (in Java and C++ at least) are implemented using binary heaps.