Drag the slider. The picture is sent through a channel that flips bits at random, and a Sparsr processor in your browser tries to work out which ones.
The thing to watch for
At low noise the left picture is visibly speckled and the right one is perfect — not "mostly right", exactly right, every pixel.
Keep dragging. Somewhere around four percent the right picture stops being perfect, and within another two percent it falls apart completely.
That edge is the code's threshold. Every error-correcting code has one. Below it the decoder works out where the damage is and undoes it; above it there is too much damage to tell which bits are wrong, and guessing makes things worse. It is a real property of the code, not a number we picked.
There is a shoulder before the fall. Just past the threshold the decoder still undoes most of the damage — it stops being perfect well before it stops being useful, and the page reports how much of the damage it removed rather than calling every imperfect result a failure.
Keep going and the corrected picture becomes worse than the raw one. That is not a bug in the page. A decoder that has lost the thread is flipping bits on bad evidence, and every wrong flip adds an error that was not there before.
What the Sparsr device is doing
The code works by parity checks. Each check takes a fixed set of the transmitted bits and asks whether an odd or an even number of them are set. If a check comes out wrong, at least one bit in it is wrong. Which bits fail which checks is what tells the decoder where to look.
Each parity check is one Sparsr instruction. The check picks out its bits with an AND
against a 4,096-bit register, and the machine reduces that whole register to a single parity
bit as part of the same operation. The demo runs 768 of those per codeword per round.
The bit-flipping is not on the device, and the page will not pretend otherwise. Once the checks are in, deciding which bits to flip means counting numbers between zero and three, which is ordinary work that a wide register does not help with. It happens in the browser. The parity checks are the part a 4,096-bit ALU makes cheap, and they are the part that runs on Sparsr.
The code
A regular (3,6) Gallager low-density parity-check code: 1,536 bits on the wire carrying 770 bits of picture, so about half of what is transmitted is redundancy. The picture takes four codewords.
The decoder is bit-flipping — find the bits sitting in the most failed checks, flip them, try again, up to twenty-four times.
A stronger decoder exists and is what real receivers use. It is called belief propagation, and it works in real numbers rather than in bits, so this processor could not run its inner loop at all. We show the decoder the hardware actually answers rather than the one that would give a better-looking cliff.
The picture
The Sparsr mark, at 64×48 with one bit per pixel — a pixel is either ink or paper, and a flipped bit is a flipped pixel with nothing in between.
We tried photographs first. At this size, in one bit, a photograph turns into an even field of speckle, so the damage and the picture look identical and there is nothing to see. Line art with large flat areas shows a wrong pixel as obviously wrong.
At this size the lettering does not survive — what you are looking at is the mark, not the company name.
What this does not tell you
Nothing about speed. The processor here is a software model running in your browser, so how long a decode takes is a property of your laptop rather than of Sparsr. The instruction counts are exact; there is deliberately no timing figure beside them.