Thread

Can gzip be a language model?

414 points · 165 comments · networked

jll29 · 1790067648 · focus · HN ↗
Yes: you can classify a test file by topic with gzip as follows:
```
  gzip -9 sports.txt   testfile.txt

  gzip -9 politics.txt testfile.txt

  gzip -9 business.txt testfile.txt
```
(ass. sports.txt politics.txt and business.txt are text docs pertaining from the sports, politics and business domains, respectively, and have equal size)
The test file belongs to the topic with the smallest size *.gz file.
Witten's group at Waikato uni were perhaps the first to work on this.
Also check out the Hutter prize if you are interested in this.
1. LPisGood · 1790073275 · focus · HN ↗
  There are some deep connections between machine learning, compression, and cryptography with information theory as a common thread.
  Also, I’ve never seen “ass.” Used to shorten “aside” — I typically use N.B. but perhaps only for important ones.
  1. shoo · 1790074503 · focus · HN ↗
    For anyone wanting an introductory text for information theory & that explores some of these connections & applications, it's worth checking out the late David MacKay's 2003 textbook Information Theory, Inference & Learning Algorithms <a href="https://www.inference.org.uk/itila/" rel="nofollow">https://www.inference.org.uk/itila/
  2. arrowsmith · 1790074634 · focus · HN ↗
    3Blue1Brown has a good video about this: <a href="https://www.youtube.com/watch?v=l6DKRf-fAAM" rel="nofollow">https://www.youtube.com/watch?v=l6DKRf-fAAM
  3. matzf · 1790076082 · focus · HN ↗
    The "ass." more likely stands for "assuming".
    chrisweekly · 1790080295 · focus · HN ↗
    Yeah, I read it as "assuming" too.
2. stingraycharles · 1790073336 · focus · HN ↗
  Back in the day - maybe two decades ago - I implemented language detection like this.
  I seeded gzip compressors’ dictionaries with Wikipedia articles in different languages.
  I would then try to use said dictionaries on any random text, and the one that was best able to compress it, was the correct language.
  Absolutely totally not the best approach, but very fast and super simple to implement.
  1. actionfromafar · 1790084214 · focus · HN ↗
    Sounds like the best approach. :)
  2. ape4 · 1790085725 · focus · HN ↗
    Or maybe make a list of the most used 1000 words in each language. And see which list has the most occurrences.
    wongarsu · 1790087162 · focus · HN ↗
    That requires you to decide what a "word" is, which is not trivial (if you think that ignoring punctuation gets you to a clean "letters surrounded by spaces" you will get lots of issues with various Asian languages)
    Also some languages have a lot of prefixes and suffixes on their verbs or even nouns, which dilutes your list of 1000 words by just adding the same common words over and over again with different suffixes designating grammatical tense, grammatical gender, etc.
    The gzip version sounds more general and more obviously correct
    basilgohar · 1790088048 · focus · HN ↗
    Instead of deciding on words, maybe you can break them up into smaller, subword parts – let's call them "quantums". And these quantums can be the units the quantumizer works on to operate on inputs and outputs. We can then use them to build Expansive Dictionary Models, or EDMs. I suppose we'd need a software library to mak working on this easier, think something speedy, fast, hot, like fire: we can call it PHPFlame...
    ashkankiani · 1790096993 · focus · HN ↗
    I'm guessing this is an allusion to reinventing something that already exists, but do you mind explaining what that is to me, since I don't know?
    BobaFloutist · 1790097578 · focus · HN ↗
    I suspect they're talking about LLM tokens.
    dspillett · 1790097624 · focus · HN ↗
    It is describing essentially how tokenisation is done for LLMs (Large Language Model → Expansive Dictionary Model).
    giancarlostoro · 1790100793 · focus · HN ↗
    You mean Quantumnisation ;)
    kragen · 1790088619 · focus · HN ↗
    You can just use 2-grams of Unicode code points.
    npb · 1790214362 · focus · HN ↗
    Very much agree. Character bigrams will solve this perfectly with tiny amounts of training data (like a couple KB).
    thesz · 1790091939 · focus · HN ↗
    Byte Pair Encoding [1] will be different for different languages. Application of the per-language BPEs to the input text will produce encodings with different lengths.
    [1] <a href="https://en.wikipedia.org/wiki/Byte-pair_encoding" rel="nofollow">https://en.wikipedia.org/wiki/Byte-pair_encoding
    It naturally takes care of common prefixes and suffixes.
    It is easy and fast to apply using radix tree or with finite automata. Even without radix tree, it is possible to have processing speed in the range of hundredths of thousands of bytes per second.
    colejohnson66 · 1790104113 · focus · HN ↗
    Even German has issues with "letters surrounded by spaces". They love to smash words together to get one giant word.
    <a href="https://www.youtube.com/watch?v=m8niIHChc1Y" rel="nofollow">https://www.youtube.com/watch?v=m8niIHChc1Y
    wodenokoto · 1790106768 · focus · HN ↗
    Just collect common bi- and trigrams and a naive bayesian classifier.
    ignoramous · 1790114779 · focus · HN ↗
    See: Fast Static Symbol Table: <a href="https://github.com/duckdb/duckdb/pull/4366" rel="nofollow">https://github.com/duckdb/duckdb/pull/4366
    FSST is based on a fixed size (255 items) dictionary of high frequency variable length strings/substrings (learned from the corpus) encoded as one byte.
3. woadwarrior01 · 1790073684 · focus · HN ↗
  aka Normalized compression distance (NCD). Its close cousin: Normalized Google distance (NGD) is also super interesting!
  <a href="https://en.wikipedia.org/wiki/Normalized_compression_distance" rel="nofollow">https://en.wikipedia.org/wiki/Normalized_compression_distanc...
4. m-hodges · 1790078812 · focus · HN ↗
  [dead]
5. myrmidon · 1790084526 · focus · HN ↗
  Nitpick: Doing it exactly like this is flawed because you let the compressibility of your references taint the result; what you would prefer is the compressed size of testfile given sports.txt/... as a dictionary without accounting for the compressed size of that, no?
  Really interesting approach though.
  1. [deleted] · 1790136237 · focus · HN ↗
    [deleted]
  2. akoboldfrying · 1790136536 · focus · HN ↗
    You're right, you should subtract off the compressed sizes of the respective reference files before comparing. (This suffices if we assume that later input data does not influence the compression of earlier input data, which is true except for certain unusual conditions like a repeated substring at the end of the reference data that also appears at the beginning of the test data.)
6. Lerc · 1790085672 · focus · HN ↗
  I seem to remember it being shown for character recognition via JBIG. Maybe in Managing Gigabytes?
7. ape4 · 1790085848 · focus · HN ↗
  There would be some overlap with business sports analogies - eg team huddle.
8. chris_va · 1790085998 · focus · HN ↗
  We used a similar technique for a class project (N decades ago) to test this:
  <a href="https://en.wikipedia.org/wiki/Baconian_theory_of_Shakespeare_authorship" rel="nofollow">https://en.wikipedia.org/wiki/Baconian_theory_of_Shakespeare...
  By looking at mutual information from different authors on the same topic vs same author on different topics. As I recall, it convincingly disproved the hypothesis.
9. [deleted] · 1790086044 · focus · HN ↗
  [deleted]
10. anthk · 1790106097 · focus · HN ↗
  Is pigz faster?
11. jjtheblunt · 1790106855 · focus · HN ↗
  we were doing this in Qualcomm 20 years ago
12. mrtnmcc · 1790106938 · focus · HN ↗
  You might also want the topic files to be compressed against each other to get a baseline matrix and then multiply any results by the inverse, assuming equal priors on the topics.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.