for example let us imagine that the word slided p letters.

My usual reaction to that is Why? How come? Where do you get p from? Terrible, I know. I am assuming here that p is an already bound variable, whereas it’s just an hypothetical value, unbound. Grrr. Works every time!

As for KMP, as you know well, I am fighting with the KMP-SUPPLY function – well, it’s again in your hands now

Ah, I see. My figure is not self-explanatory:-) Okay, first, I did not calculate p (sorry). My picture is a snapshot of a word sliding along a text and a prefix of the word matches the text. Therefore there is an index in the text corresponding to an index in the word where the letter comparison fails. Let us call the former j and the latter i. That’s all. Then, we represent the word at a slided index, for example let us imagine that the word slided p letters. Thus the index of x[1] now corresponds to previous x[p+1], which, in turn, is none other than t[j-i+p]. Why the latter? The failure index in the text is, by definition, j. Then, if you want the index of the letter of the text that matched the first letter in the word, since the failure position in the word is, by definition, i, it is j-i. Now, after sliding the word, you want to know the index in the text corresponding to the first letter in the word (again). Since, by definition, we slided the word of p positions, it is j-i+p. You see?

You really must see what happens in figure page 14 before going on… When the comparisons start again (after the sliding), in the naive algorithm, we compare x[1] to t[j-i+p] and so on, right? But this section of the text matched previously the word, when it was p letters to the left! So we are comparing a prefix of the word with a suffix of it… This enables a preprocessing of the word, independently of the text, to find the maximum-length borders, which are the longest proper prefixes which are suffixes too. Then, we slide of the length of the maximum border of the previous word prefix that matched, say w, and we resume the comparisons at x[1+|Border(w)|] instead of x[1].

Yeah, you are right, I am too serious here, I am not so serious, usually. It’s that I am concerned about you…:-D

Java is better than C++, where the implicit semantics of so many constructs makes the whole language slippy. But for low-level stuff, like drivers, C++ is still a good option. The design of Java is no bad, it is a bit too verbose, right, but I see some problems which are not due to the language itself: (1) the virtual machine is a nice concept (which originated, by the way, in functional languages, see LISP and Caml) but it is very hard to write an efficient virtual machine — nowadays this improved, but still — (2) the marketing makes you believe that, once you have the byte-code, you can run it on every platform: that’s bullshit (3) which brings me to the problem of third-party libraries: how many times did I download a Java byte-code and wasn’t able to run it just because I don’t have Sun SDK (of whatever the name nowadays)? I wan’t my intelligence back! Ah, and the memory footprint of Java application is also concerning. But, again, the language itself is really fine.

I think that you can really understand compilers because of your linguistics skills, but you need to learn first things first. Actually: re-learn. So: forget. That’s. Difficult.

I will send you a version of Knuth-Morris-Pratt in Objective Caml, written by a friend of mine, which is 40 lines long with comments, blank lines and even an optimisation:-). It’s just for giving you a taste of Caml (which is strongly statically typed, which means that the compiler has a heavy stick and is watching you, but in the other hand you don’t need to write the types explicitly).

Everything is in the definition of the maximum border of a word. But there are no assumptions. The key point is to see why in figures at pages 14 and 18.

See…? Where you see definitions and key points I see assumptions and tricks. I still have a long way to go! Not that I mind: L’espoir fait vivre.

In order to not miss any match, we must be careful not to slide too much at a time,

Yes indeed, which is why I dubbed this trick an “assumption” – I *know* it is not an assumption, but I failed to see how it was a calculation, and not playing the lottery. That is, how in botheration did you calculate p in (j − i + p)? The problem being that, as a good math wizz, you postulated a theory and backed it up with a demonstration, something that flies completely over my head: I need the demonstration first and then the postulate. My first reaction in seeing p was: what is p and where does it come from? Duh. So now re-reading the part about MP, and *backtracking* to page 13/14 – having understood, I hope, the concept of Border, Beta and supply [well, that last one, not sure yet], I think I understand that cute little p. In my own words:

After a failure [hopefully after more than 1 character in x], we want to slide more than 1 character in t like naive does, so we’d better ascertain that within the part in x that *did not* fail there is a border [prefix and suffix] of a substring of t, which could be schematized as b w b [Border, Word, Border]. If so, we can safely slide x by YY characters, YY being the length of the prefix + the length of the word inside the border, ie |b| + |w| [another way I think of calculating p = i − 1 − β ( i − 1 ), I think]. This is because we know that the next match of the prefix within t is the suffix. Simple, but very clever, like Colombus’ egg.

You have the right to slap me silly if I got it wrong, again… And thanks for making that clear. I *do* think I understand. And now that I do, I’d like to shake MM. Morris & Pratt’s collective hand. I am properly wowed. Seriously.

But then I had a thought: if we can slide t to j-i+p, why start again at x[1]? Why not slide the pointer to x too, to x[|b|+1], b being the border? Since this part has been covered too, after all, right? Duhuhuh. Sure enough, that’s what the algorithm do. No ground-breaking discovery here. Sigh… At least that’s my understanding so far.

Now, about languages. I agree whole-heartedly with you. One reason – I think – I am good with human languages is because I have a formal training in linguistics, especially phonetics and phonology [other classes, I mostly looked at the girls], which are basically the theory behind sounds and speech patterns. For instance, you can learn by rote that b, d and g between two vowels are pronounced ϐ, δ and γ in Cuban Spanish, and hope you remember, or that plosives are spirantised at inter-vocalic position. I’d rather memorize that one rule [especially since it helps explaining descrepancies in Modern Korean like 덥다 > 더운, which point to a Medieval Korean intervocalic spirant ϐ weakened into w later, but I friggin’ digress].

So yeah, what you said.

Now, you need to be a little less serious, or rather lower your shields when you detect bullshit made in dda… When I went off on a tangent on paradigm shifts and Hello World, I was of course taking a shortcut, half-joking. I won’t do graphics processing in Python [the PIL notwithstanding], and I’d rather not drink a single glass of wine rather than code OpenGL code in Erlang [or Prolog, which looks amazingly similar in syntax, but that’s no surprise: the first Erlang emulator was written IN Prolog. SO guess what? I installed gprolog… Sigh!]. And my friend Damien notwithstanding, I wouldn’t use Java for anything serious. You think Erlang is verbose?!? [BTW, 40 lines to implement Morris-Pratt, is that really verbose? Besides, I love chiding Java users…]. But in the end you’re right: I need to be able to do with comp sci what I can do with linguistics. So far I’m more of a collector of languages than anything else [can’t complain though, it’s fun!]. Too bad that when I was a student you had to go through two years of maths and crap before you could go to a comp sci department… But that’s the French way I guess.

Thanks for all this Christian, I hope you get something out of it: I surely do!

print_string “Hello world!”

That’s it. But that doesn’t actually implies that it is easy or efficient to use Caml for intense string processing applications… or that is not easy or not efficient.

There is no such thing as “all-purposes programming language”. There are always design principles, paradigms, that lean towards certain kind of applications. I think that the most erroneous idea I found in the head of many people, from students to university professors, is that “One language is better than another.” Nobody seems to realise that we live in the post-Babel era and that is a good thing: use a given language for this part of the application, another for this part and so on, each being especially suited for the corresponding task.

Of course, this requires to learn not just many languages, but some language theory, exactly like linguistics.

What do you think?

The naive search did not re-use any information between two successive matching attempts. The idea of Morris-Pratt is to re-use some information after a failure for improving the next attempt. Indeed, after a failure (at the grey position in the figure page 14), you know something, even if it looks obvious: a proper prefix (until the failure position) of the word has been matched in the text. This is x[1..i-1]. It is the equivalent of the chicken’s _sot-l’y-laisse_. Indeed, the next attempt, after sliding the word with respect to the text, will compare a prefix of x[1..i-1] to a suffix of itself. Don’t think, just look at the picture page 14 and see. You must see it before going on.

Then, you deduce that the next attempt will match x[1..i-1] if and only if this prefix is a border of x, i.e. it is both a prefix and a suffix (figure page 18). In order to not miss any match, we must be careful not to slide too much at a time, that is why we need to consider the maximum-length border of x, noted Border(x[1..i-1]), whose length, by definition, is written beta(i-1).

An now the good news: we do not need to compare again the letters of Border(x[1..i-1]) against the letters of t, precisely because it is a border of x[1..i-1], which previously matched the text. Therefore, we resume the comparisons at position 1+beta(i-1) in the word (and j in the text).

Is it clearer now?

The one thing that disturbs me in the Morris Pratt – or at least in what I understand of it, is the calculation of the sliding offset. It seems to work, but it still looks like it’s making dangerous assumptions. But at the same time, I think that the trick is in the border, [BORDER and β, and ultimately s(i)], which makes these assumptions fail-safe. But I have yet to see how THAT works.

It seems that Erlang itself is a bit verbose, isn’t it? But the fact that it is not suitable for algorithms on strings doesn’t mean that it is not “user-friendly”. The fact that you don’t have pointer arithmetic is user-friendly, for example (unless you are writing a driver, for example).

Most importantly, you should know that I met several doctors in computer science that would (and did) acknowledge in private that they do not understand Morris-Pratt and akin. Contrary to what you may think, it does not mean that these algorithms are inherently difficult, but that when one is lazy, everything is obscure.

The sad truth is that, even a doctor in comp. sc. must spend some time and energy to think. Too many professors do not think, they just repeat themselves. Student usually do not notice, but I do.

I spent a lot of time writing my slides because familiarity, intuition, needs time to come.

So it has nothing to do at all with your painful math classes of the past. Realising that is a huge liberation, because your failure to understand now is then no more emotionally associated to your past failures, so you keep trying again and again.

The key point is: do not be afraid of thinking, of giving up mechanisms — which are the hallmark of robots. Thinking is naked freedom. For what I read of you, I think that you can do it. Your brain is definitely working well.

Oh… and that’s too bad that burgondy wine is expensive in Seoul… I wish you good luck in your businesses (I know you are from Bordeaux but maybe exporting burgondy wine?;-)