Pretty Diff - A Diff Algorithm

It is more about the equality than the differences

A good diff algorithm will attempt to identify as much equality as possible. Everything else qualifies as differences. The metric for quality and precision is a smaller count of captured differences. The smaller this number the better, presuming differences aren't escaping undetected.

False negatives, which is allowing differences through without detection, is really bad. This is absolute failure in a diff algorithm. False positives, which is identifying more differences than there actually are is also bad, but a false positive is much better than a false negative. This means it is safer to report more differences than are actually present, which is why a higher number of reported differences is less precise. Maximum precision is reporting differences without any false negatives or false positives.

One way to achieve higher precision is to first capture as much equality as possible. For everything else that is left over prioritize unique items first and report these items as differences. Finally determine the next bit of equality or uniqueness and everything in between is either a change, an insertion, or a deletion.

Algorithm quality

The primary priorities when writing this kind of code are execution speed, precision (as previous described), and code simplicity. In most cases precision is the most important factor in code design, but in some cases speed is more important when processing large input or a batch of thousands of files. Simplicity is necessary so that other people can understand the code and modify it as necessary to improve upon the design and additional features. No algorithm is ever capable of meeting all needs for all use cases, so it is important that other people can understand the code with minimal effort.

Speed

Faster execution is the result of a couple of things. The most important consideration for making an algorithm faster is to reduce the number of passes through data where possible. After that eliminate all costly operations. In most programming languages simple arithmetic and static string comparisons are cheap to execute particularly if the examined strings aren't changing. The theoretical minimum number of data passes is two as you have to read the contents of each submitted sample. Pretty Diff achieves speed in its algorithm by only 3 complete passes through data and taking all possible effort to never repeat a step or loop iteration. The Pretty Diff approach is linear and predictable where the number of interations passing through data is computed as: number of iterations from the first sample + number of iterations from the second sample + the number of iterations from the smallest of those samples. Performance of the mentioned approach is heavily based upon key access in a hash map, which will likely vary by programming language.

The theoretical minimum number of data passes is two as you have to read the contents of each submitted sample. Until we discover a way to perform a comparison without reading from the samples we can safely assume 2 data passes is the fastest possible approach. Between that and the Pretty Diff approach there are two possibilities for increased performance. The first possibility is to make decisions and write output immediately upon reading from the second sample so as to have only two data passes. The challenge with this approach is that analysis occurs in the moment of the current loop interation without knowledge of what comes later in the second sample. A more practical second performance possibility is to write a smaller hash map. Writing a smaller hash map means moving some of the decision tree up front before a separate formal analysis phase. In order for this approach to be viable this early step in logic must be tiny, non-replicating, and a different means of iteration must be devised to account for a data store of unpredictable size.

This page blew up on Hacker News recently and many comments suggested this approach could not possibly be faster than the Myers' O(ND) approach. That may or may not be true and no evidence was provided either way (conjecture is not evidence).

In terms of experimental criteria algorithms are themselves largely irrelevant. More important is the implementation of those algorithms. If exercising the Myers' approach makes fewer decisions and has fewer total data passes, as described in the previous paragraph, then it likely is faster. I am calling out the word total because this makes all the difference. Many of the diff applications I looked at don't provide a complete third data pass. Instead they provide the minimum two complete data passes over the samples and various smaller passes as calculated by block moves and edit distances. If these various fractional passes are non-linear, which means starting and stopping in different places respectively, their performance is less predictable. If these fractional passes are non-linear and touch any given data index more than once they have repetitive logic, and likely are not as fast. To affirmatively guarantee superior performance over the Pretty Diff approach there needs to be fewer passes over data, which means no repetition and a smaller number of iterations. Preditability ensures the performance of an application scales roughtly proportionately to the size of the provided samples, where an unpredictable approach would scale disproportionately (slower over time). I say roughtly because things in physical reality always mess this up like: solar flares, memory block limitations, CPU heat, and so forth.

I believe the approach taken here is fast. I honestly cannot say, scientifically, it is the fastest ever (or slowest) approach for its level of accuracy without also writing alternate algorithms into applications with identical application constraints. Neither can anyone else. I can safely say this approach is the fastest ever comparative algorithm for its level of predictability and precision.

Output format

The Pretty Diff algorithm inherits its output format from the application jsdifflib. The output is a big array containing child arrays at each index. The child arrays each contain 5 indexes in the format: type, start in first sample, end in first sample, start in second sample, end in second sample. There are 4 types defined in the output: "equal", "replace", "insert", "delete". The "equal" type means both array index items are identical at the indexes compared. The "replace" type means that changes are present in the indexes compared. The "insert" type means the index of the second sample is unique to the second sample. The "delete" type means the index of the first sample is unique to the first sample.

Getting by with a hash map and some counts

The Pretty Diff algorithm takes after the Paul Heckel algorithm. First thing is to transform the string input into arrays. The most primative way to do this is to split the input by lines where each line of input is an index in an arry. Once the two input samples are converted to arrays they will each have to be examined.

The first loop will walk through an array representing one of the code samples and make a decision for a hash map which I call table in the code. I simply named the two arrays one and two. Each index of the array, by default a line of code, will serve as a key in the hash map named table. If this key does not exist then we will add it. The value for each key is an object with two properites named one and two. These properties are simply a count indicating the number of times the key is encountered in the two arrays. If the key is already present then we will simply increase the value of properties one or two respective of the current array.

Here is an example of this step in code:

The third and final pass through the data

Once the table is fully populated with all indexes from both arrays one and two we need a third and final loop to walk across the data and make some simple decisions. Here is this complete step in code.

Before I go any further I want to be clear this logic is fast and simple, but it isn't precise at all. We will fix this later with a child function named fix. I chose to make corrections for precision as a secondary step so as to not disrupt performance and isolate complexity into a separate single location.

In this code references a and b are simply positive integer incrementors. The a reference is always associated with the one array while the b reference is always associated with the two array. This is necessary so that each array may increment independently without collision. The c and d references are secondary incrementors used as closures in the child functions. These secondary incrementors allow for child loops to occur without mutation to the primary incrementors.

The first thing that happens in this loop is an attempt to discover equality. Everything else is less important and so happens later in the decision tree.

The second rule is to identify items that occur only one more time in each array. If the next item to occur in the arrays is not equal but occurs just once more then we know the item is a unique change.

The third rule is to determine if the current item is a deletion. If the current item, and possibly additional following items, is present in the first sample but no longer exists in the second sample then it is a dynamic deletion.

The fourth rule is the same as the third rule but in reverse to determine dynamic insertions.

The fifth rule is to determine if the current occurs exactly one more time in the first sample than in the second sample and yet is not a match for the next item in the first sample with two items up in the second sample. This is a static deletion, or rather a deletion of a fixed number of items.

The sixth rule is the same as the fifth rule but in reverse to determine static insertions.

The seventh and final rule determines that the current items in the samples are non-unique changes.

The child functions are as follows:

It must be noted that most of the these child functions do contain their own loops, but these loops are not duplicates. The primary parent loop, the so called third and final loop, is adjusted forward by the distance these smaller loops increment so that there is no repetition or lose of execution speed.

The fix function

We can see from the child function code that arrays are generated which appear to be the format described as the child arrays of the output. Instead of pushing this data to the output array directly instead we are passing it through a function named fix which serves as a sort of quality control filter. This function checks for things like:

• A diff type immediately following the same diff type, which can be combined into a single child array for the output
• An insertion immediately following a deletion, or vise versa, which should likely be a replacement
• Whether false positives generated from replacements immediately following an insertion or deletion can be eliminated

The general idea is to only accept a child array of the output as an argument and the make a decision after comparing it against the previous child array of the output. Aside from two narrow edge cases there is no analysis of the original data. Think of it like an appeals court in that no new evidence is allowed, because only the laws under scrutiny.

The code for the fix function is as follows:

Done!

That is the entire diff algorithm. Comments, feedback, and pull requests are welcome. Here is the complete function used in the Pretty Diff application: