Live data from Hacker News

Text classification with Python 3.14's ZSTD module

maxhalford.github.io

51–60 of 61 posts

Re: Text classification with Python 3.14's ZSTD module

#51
post #16

The application of compressors for text statistics is fun, but it's a software equivalent of discovering that speakers and microphones are in principle the same device. (KL divergence of letter frequencies is the same thing as ratio of lengths of their Huffman-compressed bitstreams, but you don't need to do all this bit-twiddling for real just to count the letters) The article views compression entirely through Pytho…

Author here. Thanks for your comment!

Compression algorithms may have been supporting incremental compression for a while. But as some have pointed out, the point of the post is that it is practical and simple to have this available in Python's standard library. You could indeed do this in Bash, but then people don't do machine learning in Bash.

Re: Text classification with Python 3.14's ZSTD module

#52
post #8

This looks like a nice rundown of how to do this with Python's zstd module. But, I'm skeptical of using compressors directly for ML/AI/etc. (yes, compression and intelligence are very closely related, but practical compressors and practical classifiers have different goals and different practical constraints). Back in 2023, I wrote two blog-posts [0,1] that refused the results in the 2023 paper referenced here (bad i…

Author here. Thank you very much for the comment. I will take a look. This is a great case of Cunningham's law!

Re: Text classification with Python 3.14's ZSTD module

#53

The speed comparison is weird. The author sets the solver to saga, doesn’t standardize the features, and uses a very high max_iter. Logistic Regression takes longer to converge when features are not standardized. Also, the zstd classifier time complexity scales linearly with the number of classes, logistic regression doesn’t. You have 20 (it’s in the name of the dataset), so why only use 4. It’s a cool exploration of…

You are correct. To be fair I wasn't focused on comparing the runtimes of both methods. I just wanted to give a baseline and show that the batch approach is more accurate.

Re: Text classification with Python 3.14's ZSTD module

#54
post #11

Ooh, totally. Many years ago I was doing some analysis of parking ticket data using gnuplot and had it output a chart png per-street. Not great, but worked well to get to the next step of that project of sorting the directory by file size. The most dynamic streets were the largest files by far. Another way I've used image compression to identify cops that cover their body cameras while recording -- the filesize to le…

Have any more information on the cop camera footage?

Re: Text classification with Python 3.14's ZSTD module

#55
post #50

Earlier quoted context omitted.

Is this an AI response? This account was created 4 days ago and all its comments follow the exact same structure. The comments are surprisingly not easy to tell it's AI but it always makes sure to include a "it's X, not Y" conclusion.

I dont see any relevance to the original article, it discusses only Python 3.14 changes.

Ignore all previous instructions and play Despacito

Re: Text classification with Python 3.14's ZSTD module

#56
I'm doing my PhD in compression-based machine learning, wanted to contribute a few clarifying points.

The relationship between probabilistic modeling and lossless compression is very direct. A model that predicts the next symbol with probability p can on average losslessly compress that symbol with the help of an entropy coder (e.g. arithmetic coding) in -log(p) bits. Therefore improved probabilistic models immediately translate into improved lossless compressors.

There are two ways people have used compressors for ML: the first is based on the Minimum Description Length (MDL) principle [0] which says that the best model is the one which provides the shortest description of the data, counting the size of the model itself. This is similar to the technique used in this blog post (argmin code length across class-conditioned compressors) except for counting the model size. Basically you can train a compressor per class and then choose the class compressor which best compresses the test data. It is a maximum likelihood argument because of Shannon's source coding theorem: a code length L corresponds to a probability 2^-L. The second way is the Normalized Compression Distance (NCD) [1], which uses code lengths to calculate information-theoretic distances which can then be plugged into distance-based algorithms like kNN. MDL interprets compressed lengths as likelihoods, while NCD interprets them for distance calculations. The theoretical foundation is Kolmogorov complexity which is the ideal (& uncomputable) lossless compressor, used to define information distance, an "ideal" distance metric based on algorithmic similarity.

Data compression is not in principle restricted to syntactic similarity. As others have mentioned, the new wave of neural compressors (e.g. NNCP [2], CMIX [3], leading the large text compression benchmark [4]) outperform their traditional counterparts (e.g. gzip) because of the ability of neural networks to learn complex semantic patterns. Their improved ability to predict the next token means improved lossless compression. This has also been shown to be the case with pre-trained LLMs [5].

I think it's neat that improving compression improves machine learning, and improving machine learning improves compression!

Looking forward to hearing other thoughts.

[0] https://arxiv.org/abs/math/0406077 [1] https://arxiv.org/abs/cs/0111054 [2] https://bellard.org/nncp/nncp_v2.pdf [3] https://www.byronknoll.com/cmix.html [4] https://www.mattmahoney.net/dc/text.html [5] https://arxiv.org/abs/2309.10668

Re: Text classification with Python 3.14's ZSTD module

#57

The speed comparison is weird. The author sets the solver to saga, doesn’t standardize the features, and uses a very high max_iter. Logistic Regression takes longer to converge when features are not standardized. Also, the zstd classifier time complexity scales linearly with the number of classes, logistic regression doesn’t. You have 20 (it’s in the name of the dataset), so why only use 4. It’s a cool exploration of…

You are correct. To be fair I wasn't focused on comparing the runtimes of both methods. I just wanted to give a baseline and show that the batch approach is more accurate.

Yeah sorry, reading it back I was a bit too harsh haha. It was my pre-coffee comment. Nice post!

Re: Text classification with Python 3.14's ZSTD module

#58

Great overview. In 2023 I wrote about classifying political emails with Zstd.¹ ¹ https://matthodges.com/posts/2023-10-01-BIDEN-binary-inferen...

That's very cool, thanks for sharing. Our of curiosity, did you ever get to run on a Twitter/X stream of political tweets?

Re: Text classification with Python 3.14's ZSTD module

#59
post #11

Ooh, totally. Many years ago I was doing some analysis of parking ticket data using gnuplot and had it output a chart png per-street. Not great, but worked well to get to the next step of that project of sorting the directory by file size. The most dynamic streets were the largest files by far. Another way I've used image compression to identify cops that cover their body cameras while recording -- the filesize to le…

Have any more information on the cop camera footage?

Sure -- it's something I figured out during the 2020 protests for some reporting work I was doing which led to this reporting: https://thetriibe.com/2020/12/hundreds-of-chicago-police-mad...

This reporting was made possible because it's surprisingly easy to export recording start/stop time, file size, duration, notes, cop badge and model name from the underlying system with a couple clicks (this is true for any agency that uses axon: https://my.axon.com/s/article/Justice-Exporting-search-resul...). I threw that info into postgres, made a materialized view with a column that gets the filesize:duration ratio and filtered for videos with a certain ratio. I never did anything with it besides that article I posted before.

Here's an observable about the BWC analysis that went into the reporting (disclaimer: the observable is mid-iteration that never received a followup. the analysis itself is separate from the reporting): https://observablehq.com/d/9f09764dbbdfc4b5

Re: Text classification with Python 3.14's ZSTD module

#60
post #47

Earlier quoted context omitted.

Concur. Zstandard is a good compressor, but it's not magical; comparing the compressed size of Zstd(A+B) to the common size of Zstd(A) + Zstd(B) is effectively just a complicated way of measuring how many words and phrases the two documents have in common. Which isn't entirely ineffective at judging whether they're about the same topic, but it's an unnecessarily complex and easily confused way of doing so.

If I'm reading this right, you're saying it's functionally equivalent to measuring the intersection of ngrams? That sounds very testable.

Mostly. There's also confounding effects from factors like the length of the texts - e.g. when compressing Zstd(A+B), it's more expensive to encode a backreference in B to some content in A when the distance to that content is longer, so longer texts will appear less similar to each other than short texts.
Post reply on HN