<p>One of the easiest and most effective modern alternatives to edit distance is called the Normalized Compression Distance, or NCD.  The basic idea is easy to explain.  Choose a popular compressor that is implemented in your language such as <em>zlib</em>.  Then, given string <em>A</em> and string <em>B</em>, let <em>C(A)</em> be the compressed size of <em>A</em> and <em>C(B)</em> be the compressed size of <em>B</em>.  Let <em>AB</em> mean "<em>A</em> concatenated with <em>B</em>", so that <em>C(AB)</em> means "The compressed size of "<em>A</em> concatenated with <em>B</em>".  Next, compute the fraction <p>(<em>C(AB)</em> - min(<em>C(A)</em>,<em>C(B)</em>)) / max(<em>C(A)</em>, <em>C(B)</em>) <p>  This value is called NCD(<em>A</em>,<em>B</em>) and measures similarity similar to edit distance but supports more forms of similarity depending on which data compressor you choose.  Certainly, zlib supports the "chunk" style similarity that you are describing.  If two strings are similar the compressed size of the concatenation will be near the size of each alone so the numerator will be near 0 and the result will be near 0.  If two strings are very dissimilar the compressed size together will be roughly the sum of the compressed sizes added and so the result will be near 1.  This formula is much easier to implement than edit distance or almost any other explicit string similarity measure if you already have access to a data compression program like zlib.  It is because most of the "hard" work such as heuristics and optimization has already been done in the data compression part and this formula simply extracts the amount of similar patterns it found using generic information theory that is agnostic to language.   Moreover, this technique will be much faster than most explicit similarity measures (such as edit distance) for the few hundred byte size range you describe.  For more information on this and a sample implementation just search Normalized Compression Distance (NCD) or have a look at the following paper and github project:
<p> <a href="http://arxiv.org/abs/cs/0312044" rel="nofollow">http://arxiv.org/abs/cs/0312044</a> "Clustering by Compression"
<p> <a href="https://github.com/rudi-cilibrasi/libcomplearn" rel="nofollow">https://github.com/rudi-cilibrasi/libcomplearn</a> C language implementation</p>

<p>There are many other implementations and papers on this subject in the last decade that you may use as well in other languages and with modifications.</p>
Is there an edit distance algorithm that takes "chunk transposition" into account?
<p>I put "chunk transposition" in quotes because I don't know whether or what the technical term should be. Just knowing if there is a technical term for the process would be very helpful.</p>

<p>The <a href="http://en.wikipedia.org/wiki/Edit_distance" rel="noreferrer">Wikipedia article on edit distance</a> gives some good background on the concept.</p>

<p>By taking "chunk transposition" into account, I mean that</p>

<pre><code>Turing, Alan.
</code></pre>

<p>should match </p>

<pre><code>Alan Turing
</code></pre>

<p>more closely than it matches</p>

<pre><code>Turing Machine
</code></pre>

<p>I.e. the distance calculation should detect when substrings of the text have simply been moved within the text. This is not the case with the common Levenshtein distance formula.</p>

<p>The strings will be a few hundred characters long at most -- they are author names or lists of author names which could be in a variety of formats. I'm not doing DNA sequencing (though I suspect people that do will know a bit about this subject).</p>