should include const for the second parameter. Otherwise numbers are outputted instead of characters. (At least for MS Visual Studio 2010).

Thank you for the code and kind explanation.

I think I can't fully understand the concept of the suffix tree..

In your code, what is the role of origin_node of Suffix?

thank you.

Jason.

I have posted an overview of suffix trees and their application, along with links to my implementation in Java:

http://www.garretwilson.com/blog/2011/12/15/suffix-trees-java.xhtml

I referenced your article. Thanks again.

Garret

>Again, these observations are less criticisms of your approach

No worries, as the years go by I always see plenty of room for improvement, and I would really like to rewrite this article someday. I finally did a rewrite of an LZW article after over 20 years, and I was happy with that - maybe this one is next!

Thanks for your comments, I hope they help others trying to work through this stuff.

- Mark

The Suffix class was a little confusing from its name, as it represents a suffix from the root, yet there is some optional "leftover" part past the active node. In my implementation I called this class State following Ukkonen.

The Suffix/State and Edge end offsets you use are inclusive. In 2011, in my mind anyway, many programmers are accustomed to end positions being exclusive, and indeed it makes many of the length calculations cleaner and more intuitive.

Several equivalent variables were arbitrarily intermingled, and logic could have been further refactored and isolated. For example, in Edge::SplitEdge() the new near edge is created extending from suffix.origin_node---which should always be equivalent to the old edge's edge.start_node. Using the Suffix origin node when splitting an edge obscures the fact that edge-splitting logically is an operation completely independent of suffixes. That is, to split an edge I merely need to provide the edge to split and a length position at which to split (even though this length may have originally come from the suffix). This loosens the coupling of edge-splitting logic from the overall suffix-tree building operation, making the isolated routine more understandable and testable on its own.

In the comments to stre2006.cpp, saying "... we ... set first_char_index > last_char_index ... to flag [an explicit node]..." was confusing to me, and I looked for code that set first_char_index > last_char_index as a flag. What you mean, of course, is that the algorithm sometimes advances first_char_index > last_char_index, and we interpret this situation as such a flag. The difference is subtle, and may only reflect my particular way of thinking about this.

Lastly, whenever there is an infinite for(;;) loop, I pause to see if there is some more concise representation I am missing in my iteration logic. In fact, if I understand this correctly, it turns out that in the present implementation, when going to the next shorter suffix from the origin node (active.first_char_index++), first_char_index may be greater than last_char_index, but only by two characters (or, with an end-exclusive implementation such as mine, by only one character). When this occurs, we not only know that there is no shorter suffix in this round, but that the previous iteration must also have been explicit, which means that it must have added a new edge. Once we note this, we can exit the loop immediately. I accomplish this by turning the for(;;) loop into a do{} while(state.nextSmallerSuffix()) loop, in which nextSmallerSuffix() returns false if start>end after advancing start++ (again, using exclusive end positions). The current implementation in this situation needlessly loops back around and does the same check it made before, finding the edge that was added the previous time around before breaking. I could be wrong about this, but so far my implementation is passing the validation tests.

Again, these observations are less criticisms of your approach than awe that I was able to understand this at all, thanks mainly to reading your article. I have finished my Java implementation. After tidying up the code and added methods to make the class useful in actual string processing, I'll post a link here. Thanks again for publishing this.

The algorithm must be written to guarantee this invariant holds.

"How" is what the article is all about!

- Mark

Thanks for writing this article. It's quite helpful. I think I understand almost everything, except one sentence. You say:

"Knowing how the construction algorithm works, you can see that if you find a certain character as a descendant of a particular suffix, you are bound to also find it as a descendant of every smaller suffix."

How can we guarantee this?

Thanks
Tony (different from another Tony above)