Markov chains: PageRank and many others

June 13th, 2009

What do Google’s PageRank, procedural music composition, text generation, speech and image recognition, among many, many others have in common?

Yes, you guessed it (it was easy as the title says it ;) : Markov chains are a basic element in their respective algorithms. (Surely, there are other approaches for some of these problems, but Markov chains are widely used).

Markov chains

So, what are Markov chains? They are a process, a sequence of states, where at a given time the next state is chosen probabilistically based only in the current state. That is, they don’t have any memory longer than in which state they are at the moment.

Let’s see a simple example of a Markov chain using a weather prediction system. To simplify it, let us assume that a day has only 2 possible weather states, sunny and rainy, and they last all day. We know that if today is sunny, tomorrow will be sunny with probability 0.9 and rainy with probability 0.1. If today is rainy, tomorrow can be sunny or rainy, both with probability 0.5.

That can be represented with a directed graph with weights on the arcs:

Graph modeling the weather system

Graph modeling the weather system

Any Markovian system can be also represented by a transition matrix. In this matrix, every entry can be read as the probability of going from the state represented by the row to the state represented by the column. The matrix related to our system is:

Weather system associated matrix

Weather system associated matrix

This matrix has some nice properties. For example:

  • P to the power of n represents the probabilities of going from a given state to another in n steps.
  • If you multiply a vector representing the probabilities of being at a given state in a given moment by the matrix P, you get the probabilities of being at every step one step later. So, if we know that before we start we are on a sunny day, the first day will be sunny with probability 0.9 and rainy with probability 0.1, and if we multiply that by the matrix again, we get that the second day will be sunny with probability 0.86 and rainy with probability 0.14
  • If the system has the following two properties
    • You can go from every state to every other state.
    • The number of steps needed to go from any state to the same state does not have to be necessarily multiple of a number different from 1.

    then, as you advance steps the resulting vector converges towards what is known as steady-state or stationary distribution, which is independent from the start input. That is, there exists a number n of steps after which the probability of being in each step does not depend on the start distribution, and does not vary when advancing more steps. In our example, the probabilities of being in a sunny day in the long term are 0.833, and the probabilities of being in a rainy day are 0.167.

If you want to see more in-depth the mathematic operations to find those values, you can find them here.

Pagerank

So, how does this apply to PageRank algorithm? As you would probably know, PageRank is the algorithm used by Google Search to try to measure the importance of a webpage. As a curiosity, as the algorithm was developed by Larry Page while doing a Ph.D in Stanford University, the process was patented by the university and Google had to pay them an amount of shares sold later for $336 million in order to use the algorithm.

What PageRank (really, really simplified) does is to deal with the web as a directed graph, where each page represents a node and each link represents an edge. From a given page, all its links have the same weight. The solution to the page importance problem is the steady-state of the system. In it, probabilities of being at a given page in the long term are a function of how many pages link there and the probability of being at those pages (their importance). That is, a link to another page is like a vote, and the value of a vote is at the same time the sum of the values of the votes the linking page has.

Other applications

Although PageRank is currently a really important algorithm, it would be unfair to say that all what Markov chains can offer is that. Some other applications are:

  • Text generators: Some text is feed as input, and a graph reflecting the partial order between words is built. Then, a random walk is done while generating a new text. A variation is not to consider the state as the current word only but the last n words. Texts generated this way do not usually make sense, but you have to read a few words to realize that. Another approach is not to use words as states but characters, which produces invented words most of the time. Some examples of Markov text generators are:
    • An online generator
    • Chat bots. Kooky is chat bot learning from many IRC channels and generating replies based on what it have received. It produces great responses, worth a read! Mark V Shaney is another example of Markov based IRC bot.
    • Spam generation: Some spammers use Markov text generators to generate unique emails trying to not be caught by spam filters.
  • Spam filtering: Yes, Markov chains are on both sides of the spam battle. It is not only used by the spammers but also by the filters [PDF].
  • Ray-tracing: Markov chains are used in Metropolis Light Transport algorithm.

Of course, this list is not exhaustive. If you are interested in knowing more applications, Wikipedia holds a larger list.

Algorithms ,

Throwing some light on NP-completeness and the P=NP problem

June 3rd, 2009

I want to say first that I am an usual reader of Jeff Atwood’s Coding Horror blog. His posts deal with a wide range of interesting subjects, not delving deep into technical topics. Some time ago, though, he tried to explain NP-Complete problems and the P=NP problem (which are different things, by the way), without good results, because he didn’t understand completely the topic. Now, he tried again, but he hardly had better luck.

It seems that this is a confusing topic, and although every computer scientist, programmer, software engineer or related professional has heard about it, many, if not most of them, can’t provide a definition any better than an intuitive one, which is usually not very accurate.

I hope this post is useful to clarify the doubts some of you can have on this topic. And maybe it helps Jeff to write a third part of the “series”, hopefully better than the previous two, and matching his usual writing quality.

First of all, say that unlike what many people think, P and NP are not the only 2 complexity classes. There are many of them. Hundreds of them are being listed and explained on Stanford University’s Complexity Zoo. It’s an extremely deep topic you could spend your whole life learning about. Of course, you don’t need to know everything of it, but it’s good to know the most common classes.

P and NP

So, what are P and NP?

  • P is the class containing all the problems solvable, by a deterministic Turing machine, in a polynomial amount of time depending on the input size. This seems easy to understand to most of us.
  • NP, on the other hand, does not seem so straightforward to understand to everybody. The definition of NP is the same as given for P, but changing “deterministic Turing machine” for “non-deterministic Turing machine”. Adding these 3 letters makes the machine more powerful, so NP includes many problems which are not in P (if P != NP). You can think of the non-determinism as if, every time the machine has to explore 2 different branches, it can explore both of them at the same time. You can also view it as if, when having to explore 2 different branches, it always chooses a branch that leads to accepting (if such a branch exists). Another interesting feature of NP problems is that a solution can be checked in polynomial time by a deterministic Turing machine. So, checking a solution of a NP problem is a P problem.

The problem with non-deterministic machines is just that we don’t have them. So, to solve a problem in NP and not in P (all problems in P are also in NP, as we can just use the non-deterministic Turing machine in a deterministic way) we need to execute the branches one after the other instead of executing them at the same time, and as there can be an exponential number of them, we need an exponential amount of time, depending on the input size, to solve the problem in a current processor.

NP-complete

Another term widely used is NP-complete. When is a problem in the NP-complete class? It has to have two properties:

  1. It has to be a NP problem.
  2. If it can be solved in polynomial time, then all of NP problems can.

The second is in itself a class: NP-hard. A problem can be NP-hard and not NP-complete, because it can be of more difficult complexity class than NP.

To demonstrate that a problem is NP-complete, we can reduce it to a known NP-complete a known NP-complete problem to it in polynomial time. To reduce a problem to another means transform its input to the input of another problem, with the condition of both problems with their respective inputs generating the same output. This would be of limited usefulness if we did not have an initial NP-complete problem, but we have it thanks to Cook’s theorem demonstrating that the Boolean satisfiability problem, also known as SAT, is NP-complete.

Given that, if an algorithm to solve a NP-complete problem in polynomial time in a deterministic machine is found, then all of NP problems would be in P, and the statement P = NP would be true.

P = NP?

As you will probably know, this is a really important open question, and really hard to solve as can be seen from the fact that a million dollars has been offered since year 2000 to the first who proves either its equivalence or its non equivalence.

But, whether P = NP or not, and until the unlikely fact of that being demonstrated, my advice is to, while bearing in mind that the question is open, act as if it was demonstrated that they were different. Deal with NP-complete problems as difficult ones. If you have a NP-complete problem you have to expect exponentially large times for algorithms solving it. This means that if your input is going to be large, the best you can do is look for approximation, heuristic or other non-exact methods. They will not give you the best solution, but, at least, they will last less than the age of the universe, which is something valuable.

Complexity , , ,

Nice Compression: Huffman Coding

May 27th, 2009

In this post we are going to see a brief resume of one of the most famous coding algorithms, Huffman coding. It’s purpose is to find a way to encode information in less space than the standard one, that is, to compress information. It was developed by David Huffman and published in 1952.

We are going to see examples using plain text encoded in ASCII. Later on the post we will see how this algorithm can be applied to other sorts of data.

Basic idea

If we have some text, usually we are storing 8 bits of information for each of its characters, which allows us to represent 256 different characters. Even in the subset of those 256 characters actually being used, the frequency at which they appear is (usually) very different. That is the fact that Huffman coding tries to exploit. If we could encode frequent characters with fewer bits than characters less frequent, the total length of the coded text will usually be smaller. (Yes, if you want to encode a text where every character has the same frequency, Huffman coding cannot help you. Sorry about that).

So, we need a non-ambiguous, variable-length way to encode characters, where characters get codes with length inversely proportional to their frequency. By non-ambiguous I mean that we should have a way to know where one character’s encoding ends, and so the next one begins. For example, if ‘A’ was coded as 1 and ‘B’ as 11, and we received 11, we could not know whether it was encoding “AA” or “B”‘.

David Huffman approached this problem using a binary tree, where at each node 0 represents a child and 1 the other one, and the characters we want to encode are represented by the leaves. The most frequent characters would be, in this tree, nearer from the root, and the most rarely found characters would be in deeper levels.

Tree construction

So, how can we construct this kind of tree in such a way that it minimizes the resulting encoding length? First of all, we need to count the frequency of every character. We are going to see the set of characters as elements, each of them with an associated weight, being the weight the number of times that it appears in the text. Now, we just select the two elements with the lowest weight, make that two elements siblings of a new parent node, remove those two elements from the set and insert the new sub-tree constructed to the set, being its weight the sum of its two children. We repeat the process until we have only one element, that is, the Huffman tree, which minimizes the encoding length.

Huffman tree
Huffman tree

Using it

We want to use this tree in two ways: for encoding text and for decoding it:

  • Encoding: We have to find the path, for the character we want to encode at each moment, from the tree’s root to the leave where it is. For every node from the root to the character, insert into the coded stream the bit linked to the decision you must take to reach your target character.
  • Decoding: At first we start from the tree root. For each bit we read, we move to its related node, until we reach a leaf. In that moment we get a decoded character, and start again from the tree root.

A thing to take into account is that the decoder should have access to the Huffman tree, so we must send/store it with the encoded data. There is also the option of agreeing beforehand in some Huffman tree so we don’t have to waste space with it, but this can lead to a worse compression ratio.

We should also bear in mind that depending on the text, specially if it is short or has not much difference in frequency among characters, the fact of storing the tree can be counterproductive, but it is usually not.

Evolution and variations

A number of variations with higher performance have been built over this algorithm, but I consider that the original is much simpler and nicer.

Some of these variations consider not only characters but groups of them, or analyze if there are different frequencies of the characters in different parts of a file and then using different trees for the different parts.

Finally, just say that I have just used text examples on this post, but of course the algorithm works well on any kind of data with different values appearing at different frequencies. The fact of some codecs as MP3 or JPEG, among others, using Huffman coding as part of their encoding/decoding algorithms corroborates that and shows David Huffman’s work usefulness.

Algorithms , ,

10 reasons you should know C++

May 20th, 2009

First of all, as I know that this can be a sensible topic for someones and that it can turn to a religious war, I want to remark that I’m only saying that, for a programmer, to know C++ is a good thing to do, and I am NOT saying neither of this:

  • That C++ is the best language around, as that concept does not exist.
  • That you should use it every time you have to program something. The language to choose for a project depends, of course, on the project itself.
  • That it is the only language you should know. It is not.

Here comes the list. There are some reasons more focused at the knowledge you can get, and others more focused at work and employment issues.

1. C++ has influences in many other current languages

When other currently most used languages, such as Java or C# appeared, C++ had already been here for a while, and, as one of their goals was to substitute C++, is no surprise that they have been highly influenced by it. So, learning C++ you will learn an important subset of many other languages, making you easier to learn them later if you ever need to.

2. Huge amounts of documentation for it

As, probably, the most used language in the last 20-25 years, there are tons of resources oriented at it. Books, forums, blogs, you will find virtually any kind of help you may dream of.

3. Many code samples are coded in C++

Whenever someone, including book authors, need to write some code and the audience is not expected to share any other language, he will usually implement that code in C++. So, as in many cases you are actually expected to understand it, it would be good for you to really understand it well, in order to learn more from the source you are reading/listening.

4. It will provide you a better understanding of other systems

Some people criticizes C++ as difficult for explicitly dealing with low-level things as pointers or explicit memory management. While it’s true that in some circumstances you would get no benefit in dealing with them, and it’s then more a source of bugs than anything else, it’s also true that having a sincere, deep understanding of them will make you a better programmer, and you will have a wider comprehension of the system, even when programming on some language that abstracts those concepts.

5. Templates & generic programming

C++ provides you the possibility of programming functions not taking into account the types of some variables or some of the arguments. This opened the possibility of truly algorithmics, and has been used in many other languages since then.

6. Interfacing languages

There are lots of different libraries, and many of them are in C++. If you program in any other language, chances are that some day you will have to interface some library, and it will probably be in C++, so you’ll have to interface it, and knowing C++ will save you time.

7. Efficient machine code produced by C++ compilers

C++ has had efficiency as an objective from the start, and, while the gap has diminished in recent years, C++ compilers are still the ones producing most efficient machine code. You may find yourself in the need of writing some part of code where you must control things that higher level languages do not allow you. Knowing C++ could help you then.

8. There will always (or, at least, for a very long time) be a niche for C++

It’s true that the C++ ratio usage has diminished in the last, say, 10 years. That’s mostly because it was used for applications that did not really needed a lot of control and performance. But almost all of those applications are no longer written in C++ any more. Most of the projects being currently developed in C++ do actually have time or space constraints, and they use a C++ for a reason. Systems programming, simulations, game programming and some others are niches that are not going to switch to another language for a long while.

9. C++ projects are more interesting than the average

As pointed out by Alastair Rankine in a post which I agree with, C++ projects are over-represented in the set of interesting projects and under-represented in the rest of profitable projects. All other things being equal, working on an interesting project instead of non-interesting one is a great change.

10. You will hardly be seen as a hacker if you don’t know C++

This is very important if looking for a new job. Companies (intelligent ones, at least), when looking for programmers, prefer hackers, people with passion for programming. This, again, happens most on interesting projects, which are usually harder too. Knowing C++ you will not be immediately seen as a hacker, but the inverse applies here. There are few hackers that don’t know C++, and your reputation as a programmer will be lower if you don’t know it.

General , ,

Turning your loops faster, II

May 13th, 2009

This post is a continuation to “Turning your loops faster, I”. If you haven’t read it, you may want to before reading this one. Here we continue reviewing some loop optimizing techniques.

Loop unrolling

We saw on the previous post that there is an overhead we pay on each loop iteration. A simple idea, so, is to do in a single new, bigger iteration, the work that was done in many former iterations. This way, there are less iterations to do and less overhead per element.

Due to the fact that the most used current processors can execute instructions out-of-order, a bigger benefit can be gained from loop unrolling as long as there are no data dependencies among different iterations, as we can also avoid the pipeline from flushing in some points, and so not losing cycles. As many other optimitzations, this can be already performed by your compiler, based on some heuristics, but maybe their results are not the optimal ones. You may want to try this specially on loops with many iterations and few code instructions.

// Original loop
sum = 0;
for(i=0; i < N; i++)
    sum += a[i];

// 2-Unrolled loop
sum = 0;
for(i=0; i < N; i+=2)
{
    sum += a[i];
    sum += a[i+1];
}

You have to be sure that the number of iterations is multiple of your unrolling degree; otherwise you have to do the remaining operations, non unrolled, at the end of the unrolled loop.

This was just a simple example, in this case the compiler would probably be already doing unrolling, and maybe in a greater unrolling degree.

Using accumulators

Even if we have data dependencies, sometimes we can slightly modify the algorithm to use different variables in a loop and so avoiding the processor from having to wait for the previous result when it really doesn't needs it.

// 2-Unrolled loop with accumulator
sum = sum2 = 0;
for(i=0; i < N; i+=2)
{
    sum += a[i];
    sum2 += a[i+1];
}
sum += sum2;

This way we do not have data dependencies inside the loop .Compilers usually do not apply this optimization.

Loop collapsing

Sometimes we have nested loops that can be joined into a single loop, usually with pointer arithmetic. This optimization is usually not done by compilers, and it can also enable other optimizations.

// We have a bidimensional array, and we want to set all of its elements to 0
int a[N][M];

// Usual way of setting all elements to 0
for (i = 0; i < N; i++)
    for (j = 0; j < M; j++)
        a[i][j] = 0;

// Collapsing loops
int *p = &a[0][0];
for (i = 0; i < N*M; i++)
    *p++ = 0;

This way we have fewer loop overhead per element.

Loop fusion

This technique can be applied when we have two loops that iterate over the same set (or, at least, they have a common subset). Knowing that, we can merge both loops and have half of the previous loop overhead. Care must be taken to avoid data dependency problems. This is usually not done by the compiler either.

// We have 2 arrays, a and b, of size N. We want to increment all the elements of both arrays.
for(i=0; i < N; i++)
    a[i]++;
for(i=0; i < N; i++)
    b[i]++;

// Fusing the loops
for(i=0; i < N; i++)
{
    a[i]++;
    b[i]++;
}

Reversing order in nested loops

If we have nested loops, and use them as index to access memory, for example, to access a bidimensional array, we must take advantage of the memory hierarchy. Sometimes, just reversing the nested loops order, a big speedup can be achieved. It's important to know your language, in particular how your language stores multidimensional arrays. C stores them by rows, but there are some languages that store them in the inverse way.

I have done some tests on my machine. Here are the two codes:

// Not cache-friendly
for(int i=0; i < N; i++)
	for(int j=0; j < N; j++)
		a[j][i] = 1;

// Cache friendly
for(int i=0; i < N; i++)
	for(int j=0; j < N; j++)
		a[i][j] = 1;

First I tested with an array of 10000 x 10000 int elements. The speed-up obtained by the cache friendly version was 5.46x.

Then I tested with an array of 2¹³ int elements each dimension. In this case, the obtained speed-up was 15.14x. This is caused because the cache friendly code continues exploiting spatial locality while the cache unaware code not only does not exploit it but it's using only a subset of cache lines, because every iteration in the inner loop is accessing memory addresses with the same lower bits, which are used to know where does that memory go in the cache.

Condition evaluation order

When you have more than one condition ORed or ANDed, the compiler will short-circuit it. That is, if the conditions are ORed and the first one is true, it will not check the others, as the result will be true anyway. If the conditions are ANDed and the first one is false, it won't check the others either, as the result will always be false. So, if you have one condition much slower than the others, put it the last one, as you will avoid evaluating it some times. If you know that a condition is going to cause more short-circuits than the other ones, put it the first one so you will avoid evaluating the other conditions more frequently.

Other techniques

These are the most common basic techniques. You can usually achieve greater speed-ups from here with parallellization, using techniques as vectorization or threading, which we will talk about in future posts.

Architecture, Optimization , , ,