I am looking for a guide how to implement the deletion of an element in a red-black-tree without using a dummy node (i.e. the leaf nodes actually being null-pointers). All implementations I found on google/wikipedia and standard literature (sedgewick and cormen at al) are using a dummy NIL-node, which I would like to avoid.
For insertion, Okasaki's double-red elimination works out of the box. Insert as usual into a BST and keep eliminating double-reds until you reach the root.
Deleting a red node is never a problem. Note that one never deletes a node with two children from a BST. If you delete a black node with one child, color the child black, and you are done. Only deletion of black leaves (real ones, not dummies) are a problem. Matt Might's approach can be made to work without dummy nodes. The trick is to first turn the leaf red, using Matt's "bubbling". Then simply remove it.
Here is a solution with code.
Related
So basically im doing this for my minecraft spigot plugin (java). I know there are already some land claim plugins but i would like to make my own.
For this claim plugin i'd like to know how to get if a point (minecraft block) is inside a region (rectangle). i know how to check if a point is inside a rectangle, the main problem is how to check as quickly as possible when there are like lets say 10.000 rectangles.
What would be the most efficient way to check 10.000 or even 100.000 without having to manually loop through all of them and check every single rectangle?
Is there a way to add a logical test when the rectangles get generated in a way that checks if they hold that point? In that case you could set a boolean to true if they contain that point when generated, and then when checking for that minecraft block the region (rectangle) replies with true or false.
This way you run the loops or checks when generating the rectangles, but when running the game the replies should happen very fast, just check if true or false for bool ContainsPoint.
If your rectangles are uniformly placed neighbors of each other in a big rectangle, then finding which rectangle contains point is easy:
width = (maxX-minX)/num_rectangles_x;
height = same but for y
idx = floor( (x - minX)/width );
idy = floor( (y - minY)/height );
id_square = idx + idy*num_rectangles_x;
If your rectangles are randomly placed, then you should use a spatial acceleration structure like octree. Then check if point is in root, then check if point is in one of its nodes, repeat until you find a leaf that includes the point. 10000 tests per 10milliseconds should be reachable on cpu. 1 million tests per 10ms should be ok for a gpu. But you may need to implement a sparse version of the octree and a space filling curve order for leaf nodes to have better caching, to reach those performance levels.
I'm reading through red black tree chapter from the book "introduction to algorithms" by Cormen. In that delete chapter, it basically says if both the node and node's parent are black, then the sibling of node's parent has to exist. The text is in page 327 first paragraph.
I don't get the logic for it, like how do we deduct something like that? Is that even true?
Though I did try to implement my own version of RB Tree and I couldn't produce a tree with a subtree like
/
R
/
B
/ \
B ...
/
...
or
/
B
/
B
/ \
B ...
/
...
Basically both node and parent are black but parent doesn't have sibling. Can't produce it so far
The text is correct. The only time you can have a black node with no sibling is when the node in question is the tree root. The easy way to think of this is to draw out the B-tree equivalent, Moving red nodes up so they are part of the same block as their parent black node. When you do this it becomes easy to see that a non-root black node with no sibling is going to produce an unbalanced tree.
In fact the two options for a non-root non-leaf black node are that either the sibling is black, or the sibling is red and has two black children (even if those two children are leaf nodes and simply represented by a null value in the implementation).
SoronelHaetir is right. But there are 3 things to say about fixups of deletes:
When "sibling" is talked about, this is normally the sibling of the current Node. It is not usually parent's sibling. So if the current Node is the left child of the parent then the "sibling" is the right child of the parent.
You say "I don't get the logic for it, like how do we deduct something like that? Is that even true?". Yes it is. One of the rules is the total black Node count down every path is the same.
So in a correct RB tree, for a given node, if the left child is black, then the right child is black (or it is red and it has 2 black children). For a correct RB Tree, you cannot have any node with an unbalanced count of black nodes down all paths. The count has to be the same in every path.
The other situation where you have unbalanced black tree count is where a leaf node has been deleted and it is black, and you are in the process of restoring the black tree count. Until it is restored (which can always be done), the tree is not a valid RB Tree.
I am trying to create edges with bends for a layout. Normally, I am using a haystack edge in the graph but whenever an edge bend has to be created, the curve-style of the edge is changed to segments. Currently, I am only creating edges with single bends. I have tried the code provided in this post but it is not creating proper edges. Currently, I am using the code from cytoscape.js-edge-editing, since it is creating better results.
The main problem is that the segment-distances values which cause the bendpoint to be created at the wrong location. Since, the functions in the above provided codes are not creating proper bendpoints, what is the right way to go about this?
A sample problem is as shown:
An edge bend has to created created in the edge from n12 to n15 where n12 is the source. The values of segment-distances and segment-weights are shown in the console. Having a positive value of segment-distances creates the bendpoint at the wrong position. It was actually supposed to be to the right of n12 and to the top of n15.
Whereas in another scenario, as shown in the following figure, an edge bend has to be created in the edge from n3 and n2. And the positions of these nodes are quite similar to n12 and n15 wrt each other. Their edge is given the same values of segment-distances and segment-weights as for the edge in the previous figure. And yet, the bendpoint is created (not accurately) but almost near to the expected location. Whereas the same value of segment-distance creates the bendpoint at the opposite location in the previous scenario.
I do not understand why this is happening. Can someone please guide me as how to solve this problem?
Refer to edge-distances:
edge-distances : With value intersection (default), the line from source to target for segment-weights is from the outside of the source node’s shape to the outside of the target node’s shape. With value node-position, the line is from the source position to the target position. The node-position option makes calculating edge points easier — but it should be used carefully because you can create invalid points that intersection would have automatically corrected.
https://js.cytoscape.org/#style/segments-edges
The intersection point is different from the node centre point (position).
If you want right-angled edges, you should probably just use taxi edges: https://js.cytoscape.org/#style/taxi-edges
What is the maximum number of rotations while inserting a new element into n-element Red Black Tree?
If I'm correct, insertion that does not violate rules of RBT requries maximum of 2 rotations (2 cases). Assuming that's it, is O(1) also a correct answer?
If that's right, confirm it and please tell me, what requires maximum of 3 rotations?
A maximum of 3 operations(or 2 rotations) are needed when implementing a Red-Black Tree correctly. For example the central BST shown in this image will need 3 operations to make it confirm to the Red Black BST's rules.
Image taken from Robert Sedgewick's slides from this MOOC..
I have this code which iterates over a tree, doing a depth-first search. Every element is tackled exactly once. Very good.
-(void)iterateOverTree:(TreeNode *)node
{
NSMutableArray * elements = [NSMutableArray array];
[elements addObject:node];
while([elements count])
{
TreeNode * current = [elements objectAtIndex:0];
[self doStuffWithNode:current];
for(TreeNode * child in current.children)
{
[elements addObject:child];
}
[elements removeLastObject];
}
}
BUT: How can I keep track of the current depth in the graph? I need to know the level of depth. So for example I have these nodes:
A has childs B, J.
B has child C.
C has child D.
D has childs E, F, I.
When A is at depth level 1, then B is 2 and C is 3.
With recursion it was very easy to keep track of the current depth level. Just inrement a variable before calling itself and decrement it after calling itself.
But here with this fancy while loop that is not possible. There is no box in the box in the box happening like with recursion.
I don't really want to have to add properties (or instance variables) to the TreeNode object as this should be re-usable in a generic way for any kind of object graph.
Does anyone have an idea how to do this? Must I introduce another array to keep track of visited nodes?
I think you do need to stack the depths as well. This is what you would actually have done anyway, if you had a recursive version. It's just that the storage would be “invisible”, since you would have used the call stack instead of an explicit stack like you are doing now.
If it helps you, you could easily convert the depth-first search to a breadth-first search, by using the array as a queue instead of a stack. (Just do removeFirstObject instead of removeLastObject.) Then you would know that you always look at the nodes in order of non-decreasing depth. However, if you need exact depths, I think you still need to add some storage for keeping track of when you have to increment the current depth.
Update:
You should be able to do a DFS without the stack altogether, if instead you follow parent pointers of the node to back up the tree. That would make maintaining the depth simple. But you would have to be careful not to break linear-time worst-case complexity by rescanning children to find out where you were.
If you don't have parent pointers, it should be possible to stack just enough information to keep track of the parents. But this would mean that you put some more information on the stack than you are currently doing, so it would not be much of an improvement over stacking the depths directly.
By the way, looking carefully on your algorithm, aren't you looking at the wrong side of the array when you get the next current node? It should work like this:
push root
while stack not empty:
current = pop
push all children of current
Im not understanding your notation, but if I read correctly you process a node and add all children to your list of work to do.
If you could change that part to using a recursion, you could track the tree-depth since it would be the recursion depth.
So instead of adding the child node, recurse for each child node.
hth
Mario
I believe what you are doing actually is BFS. You are working with lists. For doing DFS, you should use a stack;
This might be useful for the depth track, you might look into the vector p (of parents)
Supposing you are doing BFS, the easiest thing to do is to introduce another queue for depth that mirrors your nodes queue. Initialize the depth to zero. Each time you push to the node queue, push the current depth + 1 to the depth queue.