Today’s problem appears with some regularity at places like Proggit and Stack Overflow and in lists of programming interview questions:

Given a binary tree t and two elements of the tree, m and n, with m<n, find the lowest element of the tree (farthest from the root) that is an ancestor of both m and n.

For example, in the tree shown at right, the lowest common ancestor of 4 and 7 is 6, the lowest common ancestor of 4 and 10 is 8, and the lowest common ancestor of 1 and 4 is 3. It is possible for an element of the tree to be its own ancestor, so the lowest common ancestor of 1 and 3 is 3, and the lowest common ancestor of 3 and 6 is 3.

Your task is to write a function that finds the lowest common ancestor of two elements of a binary tree. When you are finished, you are welcome to read or run a suggested solution, or to post your own solution or discuss the exercise in the comments below.

When it comes to real life applicability (and sheer awesomeness!), binary trees are among the highest of the pack in the realm of data structures. Because of this innocuous little fact, I decided I simply had to solve this problem right away. Let’s dive right into it!

NOTE: The Java source code for the solution described below can be found here.

Step 1

We need to represent nodes and the tree itself first. Trees are recursive identities in nature. Namely, trees are made up of trees (subtrees), which are in time composed of more trees (child nodes), which, by definition, are also trees. For instance, analyzing the tree from the problem statement, we can say 3 is the root node for 1 and 6. 6 is the root node for 4 and 7. 4 is its own root node. If we take 3 and detach it from 8, we now have a full-blown tree. In order to model these relationships in code, a class like the following would suffice:

1
2
3
4
5
6

class Node{
     private Node left;
     private Node right;
     private int value;
     private String path;
}

What we’re basically saying with this trivial Java code is that each node can have two nodes (right and left). Nodes also have a value (specifically, an integer in this case) and a String representation of their paths to the root node. This austere model has everything we need in order to solve the problem at hand.

Step 2

Once we have an instance of our tree in place, we must find a way to traverse it and determine the path from the root node to every other node. The following snippet does the trick:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

static void traverse(Node node, Stack<Node> stack){
     stack.push(node);

     if(node.getRight() != null)
       traverse(node.getRight(), stack);

     if(node.getLeft() != null)
       traverse(node.getLeft(), stack);

     StringBuilder path = new StringBuilder();
     for(Node n : stack)
       path.append(n).append(" ");
     node.setPath(path.toString().trim());

     stack.pop();
     return;
}

The algorithm used here to visit each node is famously called DFS (depth-first search). Also, notice how we’re using a stack, a LIFO data structure, to keep visited nodes accessible when we decide to map a node’s path. After computing all the nodes’ paths in our tree, we now must find the lowest common ancestor for the two nodes given. This is rather easy once steps 1 and 2 are out of the way.

Step 3

After the traverse function is executed, we have all nodes’ paths in their respective path properties. For 4, this would be the result:

8 3 6 4

Now for 7:

8 3 6 7

And for 14:

8 10 14

Now, I know what you’re thinking: how is this useful, Elvis? Well, I’m glad you asked. The answer is we must merely check which of these space-separated elements are identical for two nodes up to a certain point (starting from left to right). That is to say, for two specific nodes, the rightmost match in two paths is the lowest common ancestor. For instance, let’s say we want to find out the lowest common ancestor for nodes 1 (path: 8 3 1) and 4 (path: 8 3 6 4). We’d line both Strings up like this:

8 3 1  

8 3 6 4

We’re now going to iterate the String with the fewer elements and compare each constituent to the other node’s path. In this case, because of 1′s path, it’d be 1 vs 4. Essentially, this is what we’d ask each time: are these two elements equal? If they are, we’ve found the lowest ancestor. We move on and compare the next elements in line. We do this until there aren’t anymore items to compare (i.e. we’ve ran out of elements in the shorter path). Here’s some pseudo code that exemplifies this process for nodes 1 and 4:

Step 1: 8 equals 8? Yes. 8 is the lowest ancestor.

Step 2: 3 equals 3? Yes. 3 is now the lowest ancestor.

Step 3: 1 equals 6? No. 3 is still the lowest ancestor.

Step 4: No more elements to compare. We're done.

Step 5: Answer: 3.

Elementary, right? The function getLowestCommonAncestor does exactly what’s described here.

Step 4?

That’s it! We don’t need anything else. A straightforward solution is possible in 3 steps. Can you do better? I recommend you read some of the solutions posted at PP. There are incredible implementations there (e.g. Remco’s amazing Haskell solution).

Before we move forward, I must provide some context for the uninitiated. Here’s the problem statement from PP:

Word cube is game in which players form words from the nine letters in a cube. Words must have four or more letters and must use the central letter from the cube; at least one word will use all nine letters in the cube. The player who forms the most words wins. Many newspapers publish a word cube on their puzzle page, and Stealthcopter publishes a word cube on line daily. Wikipedia describes word cubes under the caption “word polygon.” There are twelve words formed from the word cube at right: bonnie, bunion, coin, concubine, conic, cubic, ennui, icon, nice, nine, nuncio, and union.

Your task is to write a program that finds all matching words for a given word cube. When you are finished, you are welcome to read or run a suggested solution, or to post your own solution or discuss the exercise in the comments below.

Now that we know what needs to be done, let’s focus our attention on a possible solution. But first, some essential mathematical concepts are in order.

Combinatorics 101

Math -> Maht -> Mhta -> Mhat

What do all the preceding words have in common? They seem to be permutations of a finite set (i.e. the set comprised of the letters “M”, “a”, “t”, and “h”). A permutation is nothing more than a given arrangement of a set’s elements. The notion is important because before we can exhaustively find all the possible English words that can be formed with the letters of a Word Cube, we need to compute the permutations for each combination of 4-, 5-, 6-, 7-, 8- and 9-letter words.

If you still remember anything from your discrete mathematics courses, you may know the formula to compute the number of possible permutations for a given set is the factorial of its size. Namely, if I wanted to know the number of different permutations that can be formed with the letters of the word “Math”, I’d do this:

4 x 3 x 2 x 1 = 24

We can verify this fact by generating all the possible groupings:

Math
Maht
Mtah
Mtha
Mhat
Mhta
aMth
aMht
atMh
athM
ahMt
ahtM
tMah
tMha
taMh
tahM
thMa
thaM
hMat
hMta
haMt
hatM
htMa
htaM


As it can be easily seen, the total number of groupings is indeed 24. The iterative multiplication of all the integers from one to the set’s size, inclusive,  gives us the number of different permutations without repetition. Incidentally, that’s exactly what the factorial is. The factorial is algebraically expressed as n! (e.g. 3! = 6, 4! = 24 and 6! = 720). We’d read “3!” as “three factorial”.

A combination is a similarly simple concept to grok. If I asked you to compute all the possible combinations of the word “Math”, choosing 3 characters at a time, you’d show me this:

Mat
Mah
Mth
ath


On the other hand, if I asked the same question, but instead I’d said “choosing 4 characters at a time”, you’d have showed me this:

Math

Do you see a pattern at play here? Combinations are arrangements of a set’s elements without repetition. Those arrangements are formed by taking characters out of the original set in accordance with the desired size of the resulting groupings (e.g. “choosing 3 characters at a time”, “choosing 4 characters at a time”, et cetera). In order to solve a word cube, we need to create a set with all the combinations that we’re interested on, and subsequently permute those combinations in the hopes of finding legitimate English words.

NOTE: This is a superficial treatment of two profound and very interesting concepts. If you’d like to go deeper down the rabbit hole, ask almighty Google.

NOTE 2: If you’d like to see how to compute the permutations and combinations of a set in Java code, you can read Michael Gilleland’s articles here and here. As you shall notice upon reviewing my code, I’m using his solutions extensively.

Implementation Details

Now that we’ve outlined the “hardcore” math behind the problem, let’s get to it. These are the steps we need to take if we are to successfully solve a Word Cube:

1. Find all the possible words that can be put together using the characters from the 3 x 3 grid.
2. Select the words that have four or more characters and contain the letter from the center of the grid.
3. Select the words that comply with the above criteria and can also be found in an English dictionary.
4. Display those words.

You can read the source code in its entirety here. For step (1), we need to generate all the possible combinations of the requested size (i.e. 4, 5, 6, 7, 8 and 9) and then permute each one of them. (2) is telling us that all the legal words must have the character that’s in the center of the grid. That’s an optimization right there. We don’t have to permute a combination which doesn’t have that letter. The method generateWords contains the code that’s performing these two tasks.

For (3) and (4), we need to validate and display all the generated English words. *nix operating systems (i.e. Unix-like operating systems) come with a standard English dictionary located at /usr/share/dict. Both Ubuntu 10.14 and OS X 10.5 have it. If you’re running Ubuntu, you’ll have to modify the enumeration FILES in the code so that it has the correct file names. If you’re on OS X 10.5, you have nothing to worry about. As soon as we get a set with all the generated words, checking if a word belongs to the dictionary is trivial. This is exactly what the method check does:

1
2
3
4
5
6
7

    private static void check(Set<String> words, Set<String> dict) {
        for (String word : words) {
            if (dict.contains(word)) {
                System.out.println(word);
            }
        }
    }

Here’s how the solver behaved for some cubes I threw at it:

Remember that performance may vary depending on your computer’s processing power and workload during execution. Considering that Webster’s Second International Dictionary (the default English dictionary bundled with OS X 10.5) contains 234,936 words, less than two seconds per cube is nothing to be ashamed of.

Run it!

If you’re interested in giving the solver a try, make sure you download the code and run it like this from the command line:

java progpraxis.WordCubeSolver ncbcioune /usr/share/dict

TECHNICAL NOTE: JRE 1.6 comes with a predefined memory allocation of 64 MB of RAM. This basically means your Java application has 64 MB of RAM available to do its thing and no more. If you exceed this limit knowingly or otherwise, you’ll get a big, intimidating exception (OutOfMemoryError). I completely disregarded the space complexity of my implementation (English translation: I didn’t pay attention to memory usage). Consequently, it’s very likely you’ll have to tweak your VM to allow for the successful execution of the code. If you run into any memory hurdles, just run the solver like this:

java -Xmx128M progpraxis.WordCubeSolver ncbcioune /usr/share/dict


Notice how we’re now telling the VM that it should allocate 128 MB of RAM instead of the default value. That should give the solver more than enough memory to complete its job.

TECHNICAL NOTE 2: Yes, this is a brute-force algorithm in all its glorious splendor. Aren’t those the best? If you come up with a faster, more efficient solution, please, don’t keep it to yourself. Spread the love!

Vim has the following default keyboard mappings for moving around a document:

So if you want to scroll up, you press k. If you want to scroll down, you must press j. The Javascript code that gives Firefox the ability to scroll up and down using these key mappings is this:

function captureKeyPress(event){

    if(!event)
        event = window.event;
    var unicode = event.charCode ? event.charCode : event.keyCode;
    var actualkey = String.fromCharCode(unicode);

    if (actualkey == "j")
        window.scrollByLines(20);
    else if (actualkey == "k")
        window.scrollByLines(-20);
}
window.addEventListener("keypress", captureKeyPress, true);

Now you just need to get Greasemonkey, install the script, and you’ll be all set!

Vim’s key mappings image found at swaroopch.com.

This amazing add-on for web browser Firefox allows you to execute Javascript snippets that can customize the look and feel of any site. I quickly cooked up a script that now sets the focus to the first text box on any web page. This is the ridiculously simple code that does the trick:

var inputs = document.getElementsByTagName('input');
for(i = 0; i < inputs.length; i++){
        if(inputs[i].type === "text"){
                inputs[i].focus();
                break;
        }
}

If you have Firefox and Greasemonkey, click on this link to install Focuser (you’ll see the code if you’re using a different browser). If you’d like Focuser to only do its job on certain web sites, you can easily modify the pages that are affected using Greasemonkey’s scripts manager.

Simple hacks like this make my day every time.

Greasemonkey art found at falsepositives.com.

Everything was just peachy until Thursday night. That is, until I read this guy’s blog post:

When I tell people I am a computer programmer (or one of the other terms just to be different) most of them really don’t know what that means. They vaguely understand I “make software” (i.e. I’m a software maker, another term!) but have no clue what software looks like. So how to explain how you go about doing your job?

Writing software seems like a good start. After all we type a lot of words into a blank document using an editor, hand it to the computer to figure out what we want it to do, and then see what the computer made out of it. Rinse, repeat until done.

Even that watered-down description leaves out a lot of what we do. There is no way to really explain to people the raw details of our daily existence. Ever trying explaining programming languages and why there are so many to someone who knows nothing about programming? Or writing tests, debugging, or memory management? Don’t even try unless you like glazed over eyes. Trying to point out the importance of requirements and specifications to customers is often impossible, much less to people who don’t care.

I, not wanting to take the topic seriously at the moment, left this farcical comment:

I think we should really say: “Mystical Workers”. After all, what are we if not the product of using our highly dysfunctional brains to produce unintelligible pages of weird characters for computers to understand? THAT is mystical to the tenth power!  =)

I read a few other comments and that’s when I realized that we all have different views on what we are and what we do. Defining the professional self is always a good introspective exercise (for us at least — I don’t think doctors or lawyers would have to do this). After some thought, now I wouldn’t call myself a programmer, a software engineer, a hacker, a developer or any other of those vapid terms. If you ask me, I think we’re nothing but problem solvers. Computers just so happen to be the tools we use to do the actual solving. If we had been born in the Pleistocene, we would have been the same problem-solving guys. Well, in all honesty, we probably would have been using a different set of tools (mostly rocks I’d imagine) since I don’t think computers were around 400,000 years ago.

Sometimes we have a little bit of a hard time solving the problem at hand. Coding can be a tad frustrating. And we love it!

Source: eyes-wide-open

Maybe we’re just a bunch of dreamers. To my fellow IT workers out there, how do you see yourselves as? Magicians? Programmers? Hackers? Engineers? Maybe we should add another option: none of the above.