I'm trying to learn more about Splay trees but there is very little information to be found online about the difference between Top-down splay trees and Bottom up splay trees. Can anyone tell me what's the difference between Top-down and bottom up splay trees? Is one type better than the other?
Related
I was wondering which heuristic could fit better in the following puzzle. This puzzle comes from the game "Professor Layton" and I was trying several popular heuristic like A*, Manhattan, Euclidean... and no one convince me because there are obstacles.
The problem consists in bring the ball (the red circle) to the goal (the green dotted square). Each piece can make one movement. I hear any suggest to help me solving this problem.
The problem image:
I have tried as I said before, several algorithms that could solve the problem but anyone is really useful.
I came across this interview question and was wondering why you would want to take the vertical sum of a binary tree. Is this algorithm useful?
http://www.careercup.com/question?id=2375661
For a balanced tree the vertical sum could give you a rough insight into the range of the data. Binary trees, although easier to code, can take on more pathological shapes depending on the order in which the data is inserted. The vertical sum would be a good indicator of that pathology.
Look at the code at vertical sum in binary tree. This algorithm is written assuming a max width for the tree. Using this algorithm you will be able to get a feel for different types of unbalanced trees.
An interesting variation of this program would be to use permutations of a fixed data set to build binary trees and look at the various vertical sums. The leading and trailing zeroes give you a feel for how the tree is balanced, and the vertical sums can give you insight into how data arrival order can affect the height of the tree (And the average access time for the data in the tree). An internet search will return an implementation of this algorithm using dynamic data structures. With these I think you would want to document which sum included the root node.
Your question "Is this algorithm useful?" actually begs the question of how useful is a binary tree compared to a balanced tree. The vertical sum of a tree documents whether the implementation is closer to O(N) or O(log N). Here is an article on [balanced binary trees][3]. Put a balanced tree implementation in your personal toolkit, and try to remember if you would use a pre-order, in-order, or post-order traversal of the tree to calculate your vertical sum. You'll get an A+ for this question.
Can anyone explain the Robson algorithm for tree traversal? I'm having trouble understanding what the steps of the algorithm are.
Do you happen to have an assignment due on 5/12 that you are trying to complete?
Robson tree traversals is just a way to traverse trees using a bunch of pointers. The Steps Outlined Here do a very good job at outlining the procedures.
I would recommend creating a tree with pen and paper and following the steps. It's the easiest way to wrap your head around all of pointers, and what they are doing.
I am working on a homework assignment that deals with binary search trees and I came across a question that I do not quite understand. The question asks how density affects the time it takes to search a binary tree. I understand binary search trees and big-O notation, but we have never dealt with density before.
Density of a binary search tree can be defined as the number of nodes cumulative to a level. A perfect binary tree would have the highest density. So the question basically asks you about how the number of nodes at each level effect the searching time in the tree. Let me know if that's not clear.
If I have a graph of a reasonable size (e.g. ~100 nodes, ~40 edges coming out of each node) and I want to represent it in R^3 (i.e. map each node to a point in R^3 and draw a straight line between any two nodes which are connected in the original graph) in a way which would make it easy to understand its structure, what do you think would make a good drawing criterion?
I know this question is ill-posed; it's not objective. The idea behind it is easier to understand with an extreme case. Suppose you have a connected graph in which each node connects to two and only two other nodes, except for two nodes which only connect to one other node. It's not difficult to see that this graph, when drawn in R^3, can be drawn as a straight line (with nodes sprinkled over the line). Nevertheless, it is possible to draw it in a way which makes it almost impossible to see its very simple structure, e.g. by "twisting" it as much as possible around some fixed point in R^3. So, for this simple case, it's clear that a simple 3D representation is that of a straight line. However, it is not clear what this simplicity property is in the general case.
So, the question is: how would you define this simplicity property?
I'm happy with any kind of answer, be it a definition of "simplicity" computable for graphs, or a greedy approximated algorithm which transforms graphs and that converges to "simpler" 3D representations.
Thanks!
EDITED
In the mean time I've put force-based graph drawing ideas suggested in the answer into practice and wrote an OCaml/openGL program to simulate how imposing an electrical repulsive force between nodes (Coulomb's Law) and a spring-like behaviour on edges (Hooke's law) would turn out. I've posted the video on youtube. The video starts with an initial graph of 100 nodes each with approximately 1-2 outgoing edges and places the nodes randomly in 3D space. Then all the forces I mentioned are put into place and the system is left to move around subject to those forces. In the beginning, the graph is a mess and it's very difficult to see the structure. Closer to the end, it is clear that the graph is almost linear. I've also experience with larger-sized graphs but sometimes the geometry of the graph is just a mess and no matter how you plot it, you won't be able to visualise anything. And here is an even more extreme example with 500 nodes.
One simple approach is described, e.g., at http://en.wikipedia.org/wiki/Force-based_algorithms_%28graph_drawing%29 . The underlying notion of "simplicity" is something like "minimal potential energy", which doesn't really correspond to simplicity in any useful sense but might be good enough in practice.
(If you have 100 nodes of degree 40, I have some doubt as to whether any way of drawing them is going to reveal much in the way of human-accessible structure. That's a lot of edges. Still, good luck!)