# C[omp]ute

Welcome to my blog, which was once a mailing list of the same name and is still generated by mail. Please reply via the "comment" links.

Always interested in offers/projects/new ideas. Eclectic experience in fields like: numerical computing; Python web; Java enterprise; functional languages; GPGPU; SQL databases; etc. Based in Santiago, Chile; telecommute worldwide. CV; email.

© 2006-2015 Andrew Cooke (site) / post authors (content).

## Burrows-Wheeler Transform

From: "andrew cooke" <andrew@...>

Date: Fri, 17 Feb 2006 09:26:10 -0300 (CLST)

This is very neat.  A reversible transform that makes data trivial to
compress.

The Transform:

Take the text, of length n, and generate n different texts from the
rotations available.  Note that the last character of each line is the
prefix to the first.  Then sort and note the index of the "correct"
(unrotated) line.

The transform is the index and the final characters of the sorted list.

The Inverse:

The transform characters have all the charcters in the text.  So the
leading character column can be constructed by sorting.  This gives the
first and last character of each rotated string.  Which is a sequence of
(character, next character pairs).  Which can be chained together to give
the original text (except for an arbitrary rotation, which is corrected by
the index).

The compression:

The first characters of each line are sorted.  The transform characters
are their prefixes.  So the transform will be strongly ordered if
character pairs are strongly correlated.

Wikipedia explanation -
http://en.wikipedia.org/wiki/Burrows-Wheeler_transform

Article - http://dogma.net/markn/articles/bwt/bwt.htm

Paper - http://citeseer.ist.psu.edu/76182.html

(This is the bzip/bzip2 compression method; note that it requires the
whole input - or at least a large block size - and that decompression is
faster than compression).

From http://pmd.sourceforge.net/cpd.html
From someone on pragprog (sorry, lost reference)

Andrew

### Second Order Correlations?

From: "andrew cooke" <andrew@...>

Date: Fri, 17 Feb 2006 13:20:36 -0300 (CLST)

Seems to me that the sort on the input is arbitrary.  In the different
descriptions I've read it's lexical.  But why?  It seems to me that you
could fine-tune the algorithm by using a different ordering - one, for
example, that keeps letters that occur together as close as possible.

This would increase compression because it reduces "churn" as the lead
character changes (and, to a lesser extent, for subsequent characters).

Since the sorting is necessary for the inverse there's an additional
problem - the sorting order has to be one of:
- universal
- encoded in the file (extra length)
- inferred from the transform itself

The third option is attractive because the ordering seems to reflect
similar information to the (character, prefix) pair information in the
transform.  But off the top of my head I don't see how it helps.

On the other hand, how much would this help?  As a first approximation
perhaps it is only significant when the first character changes.  That
occurs, proportionally, less and less often in large texts (since the
alphabet is fixed).

Still, it's tempting to play around...