4

I have first node of the tree. Something like that:

class TreeNode {
   int uniqueValue;
   List<TreeNode> children;
}

I want to find the most memory efficient way to print all nodes of the tree. Tree may be big or VERY BIG. It can be deep or wide. I know algorithms with recursion and with stack. What I want to find is algorithm that use fixed amount memory independently from graph size.

Tree is NOT binary!

Pavel Vyazankin
  • 1,470
  • 6
  • 18
  • 27
  • What are the restrictions on the time-complexity? Also, can an additional pointer be added in the class TreeNode? – Abhishek Bansal Dec 07 '13 at 16:20
  • 1
    Does order matter? Can you add a Boolean flag to each node so that you can mark it as having been printed? Do you care if it takes O(n^2) time? Is the tree really so deep that a normal recursive depth-first traversal would blow the stack? – Jim Mischel Dec 07 '13 at 16:36
  • 1
    If you can traverse the tree to the deepest level, print the node, and delete it (!), then start again from the top, you have a horribly inefficient algorithm - but it uses no extra memory. Is this an intellectual exercise, or are you looking for a useful answer? If the tree fits in memory it ought to be possible to recourse through (stack no deeper than deepest level of tree). – Floris Dec 07 '13 at 21:59
  • Floris, thank you! Your idea is not useful for my production but is good as it really uses constant mem space. – Pavel Vyazankin Dec 11 '13 at 07:40

2 Answers2

2

There is no such O(1) algorithm. Memory usage in the worst case is always O(N). You can "cheat" by adding fields to support traversal directly onto the graph node. This way if you are able to load the graph to memory you can traverse it (with either BFS or DFS).

bobah
  • 18,364
  • 2
  • 37
  • 70
  • @MooingDuck, how? the tree is not binary, its not balanced. – ile Dec 07 '13 at 16:51
  • @ile: you're half right, I made an assumption. Any N-ary tree can be iterated with O(max_depth) additional memory usage. – Mooing Duck Dec 07 '13 at 16:56
  • @MooingDuck, right, however if the tree is not balanced depth is O(n). – ile Dec 07 '13 at 17:04
  • @ile: I'm not sure I'd say O(n) as a "random" tree is still surprisingly close to O(log(n)), but yeah, the worst case is definitely O(n) – Mooing Duck Dec 07 '13 at 17:10
  • @MooingDuck No u are wrong the depth of random tree is close to O(sqrt(N)) – Vikram Bhat Dec 07 '13 at 17:13
  • @VikramBhat: Interesting, I've never heard that before. (I assume sqrt only applies to binary trees but your point can be generalized, so your point stands) Do you have a source for that? (I don't have a source for mine, other than what I recall hearing). I'll have to look it up – Mooing Duck Dec 07 '13 at 17:18
  • @MooingDuck - an example of O(N) worst case: `*-*-*-*-*`, go do it in O(log(n)) :) – bobah Dec 07 '13 at 17:21
  • @VikramBhat: Wikipedia says the "expectation (or high probability bounds) of the length of the longest path in a binary search tree generated from a random insertion order" is `4.311*log(n)` http://en.wikipedia.org/wiki/Random_binary_tree – Mooing Duck Dec 07 '13 at 17:25
  • @bobah: We've already established that the worst cases cannot be done in `O(log(n))`. – Mooing Duck Dec 07 '13 at 17:25
  • @MooingDuck that is the expected depth of a node in random tree but here we are concerned with expected maximum depth of random tree which is O(sqrt(N)) – Vikram Bhat Dec 07 '13 at 17:33
  • @MooingDuck here is question of similar sorts http://stackoverflow.com/questions/2331432/what-is-the-average-asymptotic-depth-of-a-simple-unbalanced-search-tree – Vikram Bhat Dec 07 '13 at 17:36
  • @ah, different definitions of random. Mine is the expected length of the longest path in a binary tree _generated from a random insertion order_, whereas yours is the average depth of a binary tree _selected at random from a set of binary trees_. Good to know both numbers, but either way, neither can be O(1). – Mooing Duck Dec 07 '13 at 17:46
  • @MooingDuck Do it in O(1) then OP >> einstien – Vikram Bhat Dec 07 '13 at 18:08
0

If the tree happens to be stored in a flat heap-like stream, such as a long parenthesized list, traversing it only takes enough memory to record your position in the stream, which takes O(log(N)) bits.

Of course, as Lior says, you could just depth-first walk it using a stack in O(log(N)) bits.

If your tree referenced every particle in the universe (1e85, say), technically you'd only need, let's see - 85 times 3.3 = 281 bits = about 35 bytes. I assume you can handle that.

Mike Dunlavey
  • 40,059
  • 14
  • 91
  • 135