Every Tree There Is

re: Every Tree There Is

jsrfc58 — Wed, 05 May 2010 15:43:31 GMT

Oops...I meant to write "ternary tree" not "tertiary tree". And...a four-node tree would be a quadtree, etc.

re: Every Tree There Is

jsrfc58 — Wed, 05 May 2010 15:33:07 GMT

Eric wrote: "Binary trees have more structure than arbitrary trees! There are two binary trees with two nodes: one with the child on the right of the root, one with the child on the left of the root. There is only one arbitrary tree with two nodes; there is no difference between the "left" and "right" child."

I think this argument depends on what function you are using to generate new nodes in the tree.

For example, if you have a binary tree, and you are adding a new value, you could create a new node on the left if the incoming value is less than the current node value. That rule is arbitrary, however, because you could reverse that and instead create a new node on the right. Now does that constitute one binary tree, or two?

Also, with arbitrary trees, it depends on how you define them. To say there is no difference between the left and the right child really depends on what type of arbitrary tree you are describing. If you have some type of function which determines how new nodes are created, they may in fact have more structure than a binary tree.

For instance, if an incoming value is compared to an existing node, you could have it create a left node if the value is less, a right node if the value is greater, and a middle node if the value is equal. (would that make it a tertiary tree?)

Anyway, you could scale this "gateway" function so that four, five, or six (or more) nodes are created. I would argue that a six-node tree would have more structure than a binary tree in this case. I haven't done the math on it, but would it possibly have 6! different configurations?

re: Every Tree There Is

hp — Mon, 26 Apr 2010 20:48:19 GMT

Generating all possible pictures:

http://aboutintelligence.blogspot.com/2008/05/generating-all-possible-pictures.html

re: Every Tree There Is

Pop Catalin — Sat, 24 Apr 2010 02:22:00 GMT

It's interesting that for binary trees the following are considered distinct configurations

A A

\ \

B B

/ \

C C

but if they are viewed as general trees they are not distinct, it's the same configuration.

There's a distinction in the definitions given for the binary and arbitrary trees, the binary tree definition contains node position information (which also implies ordering), but the definition of general trees only contains ordering information. (without position information)

If we were to define the the binary trees without any position information, something like : a binary tree is a tree where every node has a maximum of two child nodes (maybe as a linked list) then the number of possible configurations is reduced by a large factor. (Intuitively I think 2n!, but I need to verify)

re: Every Tree There Is

Mark Knell — Sat, 24 Apr 2010 00:53:02 GMT

> No, that is exactly the opposite of what I need. If A is {} and B is {{}} then I want {{}{{}}} and {{{}}{}} to be different trees. An ordered list gives me exactly the ordering I need.

My version does distinguish {{}{{}}} from {{{}}{}}, fwiw, so I don't think it's the opposite of what you need. It would produce the exact results you require.

But, it is unnecessarily complex. I think I've both introduced a wrinkle and compensated for it, when I should have let well enough alone.

Consider two graphs:

/ | \

B C D

And

/ | \

B D C

I thought a plausible reading of your original definition would say that in the first case, A's list of children is {B, C, D}, in the second it is {B, D, C}. These are different lists, but you wish them to describe the same tree.

However, this confers more differentiable identity to the nodes than I should. You've shown trees with labels, but the labels have been based on positions, i.e., labeled after order is fixed. My instinct is to quibble with this, saying, "Yeah, but what if we reverse the order in which we visit the leafs under A; it's the same 'shape' but with different 'order'." Upon reflection, I think that's begging the question. It already assumes that node identity is meaningful apart from position. That's something I cooked up; you don't distinguish nodes in any way other than their subtrees and their order relative to their siblings. It's reminiscent of the story about the three baseball umpires (which you've featured). To paraphrase the oldest umpire, your nodes ain't nothing until you've ordered them.

I've probably spent too much time serializing things lately.

re: Every Tree There Is

Mark Knell — Fri, 23 Apr 2010 22:44:52 GMT

> Let's say that an arbitrary tree is defined as either (1) the empty arbitrary tree, or (2) a list (possibly empty) of *non-empty* arbitrary trees called the children.

If you're using the same notion of ordering as you did last post, you probably want a bit more detail on how the children are ordered. Maybe something like: If two permutations of the children only transpose children that have similar subtrees, the permutations are considered equivalent.

In other words, if "list" entails being well ordered, then that's too strict an ordering for your needs. You need a collection that allows a root with children {A, B} to be equated with a root with children {B, A}.

No, that is exactly the opposite of what I need. If A is {} and B is {{}} then I want {{}{{}}} and {{{}}{}} to be different trees. An ordered list gives me exactly the ordering I need.

With these definitions it becomes plausible that binary trees and arbitrary trees are isomorphic, since both of them are recursively defined collections of pairs. A binary tree is a collection of left/right pairs, and an arbitrary tree is a collection of head/tail pairs.

re: Every Tree There Is

John Kallen — Fri, 23 Apr 2010 21:51:47 GMT

"Next time: what else can we generate all of?"

Eric: how about generalizing from binary trees to arbitrary directed graphs (including cycles). That way you could generate what amounts to control flow graphs of basic blocks. You might think of it as useful for generating control flow graphs for the testing of the back end of a compiler (or decompiler, in my case). However, the number of graphs is likely to grow very fast with the number of nodes. And attempting to filter out the many isomorphic graphs doesn't work as graph isomorphism is hard (not P, but apparently not NP-complete either).

Interesting idea. You're right, it's the isomorphic graphs that are hard to identify. Simply generating all the directed graphs with n nodes is easy; there are 2^(n^2) of them. Imagine an n by n matrix of Booleans that says whether there is an edge from x to y; there is one graph for every possible combination of Booleans in that matrix. Easily enumerated: just make an n x n bit integer and count from zero until you're done. -- Eric

re: Every Tree There Is

Philip — Fri, 23 Apr 2010 19:39:10 GMT

Just a note of pedantry;

If there are two trees of size 2 (binary), A in root with B left, A in root with B right...

The you could also say that there are four for a structured tree of size 4: A in root with B in child position 0 (nodes 1-3 empty), ... A in root with B in child position 3 (nodes 0-2 empty).

When reading your question, it was not clear to me if "any arbitrary tree" meant "a tree with an arbitrary structure" or "any structured tree picked arbitrarily". So I answered "it depends" :)

re: Every Tree There Is

Mark Knell — Fri, 23 Apr 2010 17:56:24 GMT

> It's amazing how many people get hopelessly tangled up

This is completely off Eric's topic, but it's interesting to me how common this view of technical difficulty is. Namely, that a problem that's only mildly complex in general should still only be mildly complex to solve in an interview. I used to think that, too.

Over the years, though, I've had a couple of interviews where I drew blanks on (or got "hopelessly tangled up" in) things I not only should have known, but did know cold in my everyday routine. And certainly I've been on the interviewing side of of plenty of trainwreck responses to even trivial problems, such as "in the language of your choice, write code to traverse a binary tree". The Coding Horror blog has recurring posts about even simpler sorts of problems causing difficult.

Two things changed my mind. One, I've heard that the most widely-held fear in the US is public speaking--outranking spiders, needles, planes, internet outtages, etc. For many, relatedly I think, the interview is NOT a representative sample of their technical skill.

And two, consider the last time you made an important technical presentation (say, to a client or a boss). Did you choose to do it without having prepared or rehearsed? If you rehearsed, why? For many, we rehearse because thinking things through in advance, where you can be meticulous at your own speed, is different from trying to produce meticulous results rapidly, for an audience. And that's when you know what the questions are likely to be in advance!

I'm not saying this sort of question is an unfair test of a candidate, or that speaking and thinking on your feet is not an important skill, even for a "heads down" developer. But I do think that most interviewers underestimate how technical degree-of-difficulty amplifies when introduced in an interview. They think it says something about the population, and maybe it does--but I think a significance fraction of the result can be explained by sheer anxiety.

re: Every Tree There Is

Tony Cox [MSFT] — Fri, 23 Apr 2010 16:10:18 GMT

On the theme of "generating all of...": printing all anagrams of a given input word is a question I sometimes pose to candidates in interviews. It's amazing how many people get hopelessly tangled up by it.