<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Information-Theory on CS Theorems</title><link>https://cs.lozic.me/areas/information-theory/</link><description>Recent content in Information-Theory on CS Theorems</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Fri, 02 Jul 2027 12:00:00 +0100</lastBuildDate><atom:link href="https://cs.lozic.me/areas/information-theory/index.xml" rel="self" type="application/rss+xml"/><item><title>The No-Cloning Theorem</title><link>https://cs.lozic.me/posts/t110-the-no-cloning-theorem/</link><pubDate>Fri, 02 Jul 2027 12:00:00 +0100</pubDate><guid>https://cs.lozic.me/posts/t110-the-no-cloning-theorem/</guid><description>&lt;h2 id="symptom"&gt;Symptom&lt;/h2&gt;
&lt;p&gt;You have spent this whole part learning that information wants to be copied.
Entropy bounds compression (T018), Huffman hits the bound (T020), redundancy
buys error correction (T021). Every result so far treats &amp;ldquo;make another copy&amp;rdquo; as
the free operation — the thing you do without thinking, the reason &lt;code&gt;cp&lt;/code&gt; has no
interesting failure modes.&lt;/p&gt;</description></item><item><title>The Nyquist–Shannon Sampling Theorem</title><link>https://cs.lozic.me/posts/t106-the-nyquist-shannon-sampling-theorem/</link><pubDate>Fri, 25 Jun 2027 12:00:00 +0100</pubDate><guid>https://cs.lozic.me/posts/t106-the-nyquist-shannon-sampling-theorem/</guid><description>&lt;h2 id="symptom"&gt;Symptom&lt;/h2&gt;
&lt;p&gt;Your dashboard shows CPU utilization averaging 40%, comfortably under budget.
Users are reporting timeouts. You add more logging and the average stays at 40%.&lt;/p&gt;
&lt;p&gt;Eventually someone captures a one-second trace and finds the truth: the service
spikes to 100% for eight seconds out of every ninety, and your monitoring
samples every sixty seconds. The spikes are real, periodic, and invisible.&lt;/p&gt;</description></item><item><title>Streaming Lower Bounds and Sketching</title><link>https://cs.lozic.me/posts/t105-streaming-lower-bounds-and-sketching/</link><pubDate>Fri, 30 Apr 2027 12:00:00 +0100</pubDate><guid>https://cs.lozic.me/posts/t105-streaming-lower-bounds-and-sketching/</guid><description>&lt;h2 id="symptom"&gt;Symptom&lt;/h2&gt;
&lt;p&gt;Product wants the daily unique-visitor count. You have a firehose of events.&lt;/p&gt;
&lt;p&gt;The obvious implementation is a set. Add each visitor ID, report the size. At a
billion distinct IDs, eight bytes each, that is 8 GB before any hash table
overhead, and in practice a &lt;code&gt;HashSet&lt;/code&gt; will cost you two to three times that.
Per day. Per dimension you want to slice by. Multiply by country, by platform,
by campaign, and the memory bill is absurd for a number nobody looks at past two
significant figures.&lt;/p&gt;</description></item><item><title>Minimum Description Length and Occam's Razor</title><link>https://cs.lozic.me/posts/t025-minimum-description-length-and-occams-razor/</link><pubDate>Fri, 16 Apr 2027 12:00:00 +0100</pubDate><guid>https://cs.lozic.me/posts/t025-minimum-description-length-and-occams-razor/</guid><description>&lt;h2 id="symptom"&gt;Symptom&lt;/h2&gt;
&lt;p&gt;You fit a model. It scores 94% on training data and 71% on held-out data.&lt;/p&gt;
&lt;p&gt;So you simplify: fewer parameters, more regularization. Training drops to 88%,
held-out rises to 84%. You simplify further and both drop. Somewhere in there
was an optimum, and you found it by trial and error, with a validation set and
patience.&lt;/p&gt;</description></item><item><title>Kolmogorov Complexity</title><link>https://cs.lozic.me/posts/t023-kolmogorov-complexity/</link><pubDate>Fri, 09 Apr 2027 12:00:00 +0100</pubDate><guid>https://cs.lozic.me/posts/t023-kolmogorov-complexity/</guid><description>&lt;h2 id="symptom"&gt;Symptom&lt;/h2&gt;
&lt;p&gt;You have two files, each exactly one megabyte.&lt;/p&gt;
&lt;p&gt;The first is a megabyte of the byte &lt;code&gt;0x00&lt;/code&gt;. The second is a megabyte from
&lt;code&gt;/dev/urandom&lt;/code&gt;. Gzip the first and you get a few hundred bytes. Gzip the second
and you get slightly more than a megabyte, because the header costs something and
there is nothing to exploit.&lt;/p&gt;</description></item><item><title>The Hamming Bound and Error-Correcting Codes</title><link>https://cs.lozic.me/posts/t022-the-hamming-bound/</link><pubDate>Fri, 05 Mar 2027 12:00:00 +0100</pubDate><guid>https://cs.lozic.me/posts/t022-the-hamming-bound/</guid><description>&lt;h2 id="symptom"&gt;Symptom&lt;/h2&gt;
&lt;p&gt;You are specifying ECC memory for a fleet. The vendor quotes SECDED: single
error correct, double error detect, at 8 check bits per 64 data bits. That is
12.5% overhead, and someone in the room asks the obvious question — why not
correct two errors? Or three? What does it cost?&lt;/p&gt;</description></item><item><title>The Noisy-Channel Coding Theorem</title><link>https://cs.lozic.me/posts/t021-the-noisy-channel-coding-theorem/</link><pubDate>Fri, 26 Feb 2027 12:00:00 +0100</pubDate><guid>https://cs.lozic.me/posts/t021-the-noisy-channel-coding-theorem/</guid><description>&lt;h2 id="symptom"&gt;Symptom&lt;/h2&gt;
&lt;p&gt;Your link drops 1% of bits. You need reliable delivery, so you triple every bit
and take a majority vote. Now an error needs two of three bits to flip, which
happens with probability about $3 \times 10^{-4}$ — better, but you paid 3x in
bandwidth and the error rate is still not zero.&lt;/p&gt;</description></item><item><title>Huffman Coding Is Optimal</title><link>https://cs.lozic.me/posts/t020-huffman-coding-is-optimal/</link><pubDate>Fri, 19 Feb 2027 12:00:00 +0100</pubDate><guid>https://cs.lozic.me/posts/t020-huffman-coding-is-optimal/</guid><description>&lt;h2 id="symptom"&gt;Symptom&lt;/h2&gt;
&lt;p&gt;You are compressing a log file. The symbols are wildly skewed: &lt;code&gt;INFO&lt;/code&gt; is 90% of
the lines, &lt;code&gt;WARN&lt;/code&gt; is 9%, &lt;code&gt;ERROR&lt;/code&gt; and &lt;code&gt;FATAL&lt;/code&gt; split the rest. Fixed-width
two-bit codes give you exactly 2 bits per symbol, and entropy (T018) says the
floor is about 0.53 bits. There is a factor of four sitting there.&lt;/p&gt;</description></item><item><title>Shannon Entropy and the Source Coding Theorem</title><link>https://cs.lozic.me/posts/t018-shannon-entropy-and-source-coding/</link><pubDate>Fri, 13 Nov 2026 12:00:00 +0100</pubDate><guid>https://cs.lozic.me/posts/t018-shannon-entropy-and-source-coding/</guid><description>&lt;h2 id="symptom"&gt;Symptom&lt;/h2&gt;
&lt;p&gt;You gzip a log file and it drops to 8% of its original size. You gzip the
already-gzipped file and it gets slightly &lt;em&gt;bigger&lt;/em&gt;. Somebody asks why, and the
honest answer you have is &amp;ldquo;because it&amp;rsquo;s already compressed,&amp;rdquo; which is a
restatement, not a reason.&lt;/p&gt;</description></item><item><title>No Universal Lossless Compressor</title><link>https://cs.lozic.me/posts/t004-no-universal-lossless-compressor/</link><pubDate>Fri, 04 Sep 2026 12:00:00 +0200</pubDate><guid>https://cs.lozic.me/posts/t004-no-universal-lossless-compressor/</guid><description>&lt;h2 id="symptom"&gt;Symptom&lt;/h2&gt;
&lt;p&gt;Someone sends you a pitch deck. The claim is a compression algorithm that
reduces &lt;em&gt;any&lt;/em&gt; file by a guaranteed ratio, and — this is always the tell — that
it can be applied repeatedly. Four gigabytes down to one, then one down to two
fifty, and so on until the whole film is a few hundred bytes and a clever
decoder.&lt;/p&gt;</description></item></channel></rss>