After Thoughts:
1. Our dp hash table for the tree should index by just the iterator, and not the sum, iter, and value of a node as I have done here.
2. The dp hash table for the tree should be reserved to N, where N is the size of the array. In addition, the size for the unordered_set<string> in root_leaf_paths_rec should be reserved to the maximum number of possible combinations which is ∑n=0knCk.
3. Rather than referencing the value within the array directly, it would be simpler and possible more space efficient to instead reference an index to the value within the array. With an array of strings for example, each node can reference an index to the array rather than other copy of the string. This would be simpler in the sense that the pattern that evolves from these index's become more explicit in the construction of the tree. Observe:
4. At one point I considered multi-threading each subtree form the bast root, but because every proceeding subtree is heavily reliant on the hash table - it is best be done linearly.
5. Because our next implementation will index by iterator, the accumulative summation will have to be dynamically produced at run time. This is because now each node will have multiple children and multiple parents, and therefore different relative summations depending on the parent. In other words, we will be transforming this tree into a graph.