tree-traversal | Iterative tree structure traversal library for Node.js | Dataset library

The following condition is wrong:

what is the (average) time complexity for this solution?

It is O(min(d.logn, n)) where d is the (maximum) branching factor of the nodes (2 for binary trees). The indexOf call is responsible for this coefficient. However, even if d is large, the nodes that are scanned during indexOf are never visited again, so the time complexity is also O(n) (as an upper bound). For relatively smaller d (in comparison with n), O(d.logn) better expresses the time complexity. To cover both extremes we can say: O(min(d.logn, n)). This expresses the fact that if d approaches n, then necessarily logn becomes small (the tree's height diminishes).

The worse case is easy since we need to visit each node once so it is going to be O(n), n being the number of DOM nodes in the DOM tree. I think it happens when we have two linked lists and the target node is the last node in each linked list.

True.

The confusion part for me is that for each level we are also calling Array.prototype.indexOf to get the index, and this might take up to O(D), D being the tree's diameter and for a leaf node it is going to take O((some-constant)n) to get the index.

The diameter is not concerned here. The complexity of indexOf depends on the number of siblings. In the case of a degenerate tree that really is a linked list (as you wrote), D is 1, i.e. none of the nodes have siblings, and so indexOf is always called on an array with just one element: indexOf takes constant time in that case.

We are traversing a tree twice.

A factor of 2 is irrelevant for deriving a time complexity.

It seems like it is going to be the height or the depth of the tree. If it is a completely balanced tree, the height of the tree is going to be logN. Does that mean the average time complexity is logN?

Yes. Even "almost" balanced trees, like AVL-trees, red-black trees, ... still give this logarithmic time complexity. If you create a tree randomly, it is expected that it will be rather balanced, and its height is O(logN).

If I write the solution using a recursive DFS approach, where we traverse both trees simultaneously, [...] What is the time complexity in this case?

Here you don't make use of the parent links, and so in the worst case you may have to visit each node. This makes it O(n).

Is this recursive approach better than the iterative approach in terms of time complexity since we wouldn't need to do indexOf for each level?

The indexOf strategy isn't that bad if d is much smaller than n. If however we have no idea at all whether that is the case, then the worst-case time complexity is the same -- O(n).

If d is much smaller than n, then the first algorithm has a better time complexity, O(d.logn).

While trying to debug the code, the problem seemed to be in the whole concept of the attribute next in the Node class.

When I printed out all of the Nodes' next lists, I found multiple occurences of the same Node, for example [2,2,2,3,8,...] so when I converted the list to set it didn't get stuck anymore.

Hope this helps someone in the future.

It seems to me like your stop condition is incorrect. The default values for children (and the root) are None so you should check for z == None. Also it seems like you are mixing up child nodes and keys. It seems to me the best approach would be to first find the node with the desired key and then calculate the subtree size recursively on this node. See the code below.

Like my comment suggests, you're not only printing "done with ..." for leaf nodes; instead you're doing that for every node in the tree, even intermediary ones.

I suggest changing your function as follows in order to see this more clearly:

You scan each node h(branch)-h(node) + 1 times.

See this example:

If you have a binary search tree then an in-order traversal can be used to show the elements contained in the data structure in sorted order. Seeing things in sorted order is generally useful. So if the tree has three nodes, A at the root and children B and C, and it's a binary search tree, you want:

The trick is to recursively select just the sibling row with the minimum sort value - which is the leftmost child of the current parent row: