Teenager Disproves A 4 Decade Old Belief In Computing
read summary →For forty years, theoretical computer science
has struggled to make progress on hash tables, a
basic data structure that underpins much of modern
computing. Whenever a database pulls up a customer
record, a web browser checks a saved password, or
a router sends data, a hash table is probably at
work. Think of these structures as the internet’s
filing cabinets, built for speed. Trouble starts
when the cabinet fills up. For decades, computer
scientists believed that as a hash table gets
close to full, its performance must drop. If
you try to fill a storage system to ninety-nine
percent, probability says you’ll pay with slower
speeds. Instead of quick lookups, you end up
searching through a mess. This belief was codified
in 1985 by Andrew Yao. He is a titan in the field
and a recipient of the Turing Award, which is the
Nobel Prize of computing. Yao published a seminal
analysis that seemed to set a speed limit on how
efficiently a dense hash table could operate. This
conclusion became a foundation of the field for
forty years, until Andrew Krapivin came along.
Krapivin, at just 21 years old undergraduate
student at Rutgers University, has written a paper
that has demolished this 40-year-old conjecture.
In fact, Andrew did not even know the conjecture
existed. He was simply working on a side project
about memory compression, and he needed a tool
that did not exist. He sat alone late at night,
staring at a research paper about a concept called
tiny pointers. He started tinkering with the math
just for fun. He wanted to see if he could make a
computer memory system that was just a little
bit more efficient. Little did he realize that
he was stepping into a problem that had stumped
top computer scientists for forty years. Without
realizing it, he has overturned a long-held belief
and shown that Yao’s speed limit could be broken.
To see why Krapivin’s discovery matters, let’s
look at one of computing’s biggest challenges:
how to find data quickly and efficiently. Picture
a library with millions of books. If you want The
Great Gatsby and there’s no sorting system, you’d
have to check every shelf until you find it. In
computer science, this is called linear time. As
the library grows, so does the search time. For
computers that need to work at lightning speed,
linear time just isn’t good enough. Hash tables
solve this problem. They’re like a magic trick
that lets you find the needle without digging
through the hay. This trick uses a mathematical
formula called a hash function. You put in the
data you want to store—like the title The Great
Gatsby—and the function gives you a number. Let’s
say it gives you 42. That number is an address,
telling the computer to put The Great Gatsby on
Shelf 42, Slot 1. When you want the book later,
you don’t have to search. Just put the title back
into the function, get 42 again, and go straight
to that spot. The book is waiting for you.
In a perfect world, this process is instant. It
takes the same amount of time whether there are
ten books or ten trillion. That’s why hash tables
are everywhere—they promise instant access. But
things aren’t always perfect. Hash functions are
blunt tools—they map lots of possible data onto
a limited number of slots. Sooner or later, two
pieces of data will end up fighting for the same
spot. You now have a collision. Two books cannot
occupy the same physical space. The system must
decide what to do. Engineers have two main ways to
handle this. The first is called chaining. Here,
Shelf 42 acts like a bucket—you just pile all
the books that land there into it. If more books
map to that slot, they go in too. It’s simple,
but messy. It needs extra memory to track the
overflow, and the computer has to jump around to
find the scattered data, which slows things down.
The second approach is more elegant but riskier.
It’s called open addressing. In an open addressing
system, every slot holds exactly one item. There
are no buckets. If Shelf 42 already has The Great
Gatsby, the system has to find another spot for
Moby Dick. It checks Shelf 43, then 44, and keeps
going until it finds an empty slot. As the table
fills up, the collisions become more frequent.
The empty spaces become rarer. The “hunt” for a
free slot takes longer. This is the phenomenon
that Andrew Yao analyzed forty years ago. It is
known as the problem of the full parking lot.
Everyone knows what it’s like to drive into
a parking lot that’s only ten percent full.
You find a spot right away and park with no
trouble. Now imagine a parking lot that is
ninety-nine percent full. There are one thousand
spaces, and nine hundred and ninety of them are
occupied. You drive in. You cannot find a spot.
You spend ten minutes driving past occupied spots,
hunting for that one elusive opening. In a hash
table, this search is called probing. As the table
gets closer to full, the number of probes needed
to find a spot goes way up. In 1985, Andrew Yao
wanted to quantify exactly how bad this problem
could get. He focused on the extreme regime.
He looked at tables that were nearly full.
He used a variable, which we will call x,
to represent the inverse of the free space.
If the table is ninety-nine percent full,
one percent is free. The variable
x is one hundred. If the table is
ninety-nine point nine percent full, one
tenth of one percent is free. The variable
x is one thousand. Yao studied how “greedy”
algorithms work. These algorithms grab the
first empty slot they find when storing data. They
don’t wait or look ahead—they just take the first
available spot. Yao argued that for any greedy
strategy, you are at the mercy of probability.
If only one in a thousand slots is empty, you
will, on average, have to check a thousand
slots to find one. The work required to
insert a new item grows linearly with x.
This means that if you double the density of the
table, you double the work. If you increase the
density by a factor of ten, the system slows
down by a factor of ten. Yao went further. He
formulated a conjecture about the worst-case
scenario. He proposed that among all possible
strategies for placing data in this restrictive
model, the best you could possibly do was to mimic
pure randomness. This is known as uniform hashing.
The idea is that if you scatter data randomly,
you avoid creating patterns. Yao’s conjecture
implied that randomness was the ceiling of
performance. You could not do better than
chaos. This idea became widely accepted.
It meant you had to choose: a fast hash table or
a full one, but not both. To keep things speedy,
you had to leave a lot of memory empty,
wasting valuable space just to avoid slowdowns.
Andrew Krapivin came to Rutgers with many
interests and was double-majoring in math
and computer science. He also likes to browse
research papers outside his classes. In fall 2021,
he found a paper called “Tiny Pointers”. The
paper was co-authored by Martín Farach-Colton,
a professor at Rutgers who would later become
Krapivin’s mentor. The paper tackled a problem
of compression. In a computer, a “pointer” is
just an address. It is the number that tells
the machine where a piece of data lives. In
massive systems with billions of data points,
these addresses can become very large
numbers. Large numbers take up space.
The paper proposed a clever way to
shrink these pointers to save memory.
Krapivin became fascinated by how the
problem worked. He wondered if he could
make the compression even better—could he
make the pointers even smaller? But there
was a catch. To use a very small
pointer, you need to know exactly
where the data is. You cannot afford to
have the data scattered across a vast,
sparse landscape. You need the data to be packed
tightly together. A small pointer implies a small
address space. This led Krapivin to hash
tables. To make his tiny pointer idea work,
he needed a hash table that could be almost
completely full and still run quickly.
The usual methods, such as linear probing,
quadratic probing, and the standard greedy
algorithms, just didn’t cut it when he looked into
them. They kept failing his most important test:
once the data structure started filling up,
they’d inevitably choke, which confirmed the
bottleneck Yao had warned about. But Krapivin
didn’t know about Yao or his famous theory. He
just saw that the usual methods failed, so
he set out to design his own way to insert
data. He started to question whether greedy
algorithms were really the best approach.
In a standard hash table, if the algorithm hashes
a book to Slot 42 and Slot 42 is empty, it puts
the book there. Why would it not? It seems foolish
to skip an empty space. It seems inefficient to
drive past a parking spot near the front of the
store. But Krapivin saw that greedy choices have
hidden downsides. When algorithms always take the
first open spot, they create clusters. Imagine ten
slots in a row: if slots 1, 2, and 3 are filled,
they form a block. If a new item lands at slot 2,
it’s taken, so it checks slot 3, then slot
4, and ends up there. Now the block is even
longer. These clusters act like gravity wells.
The bigger they get, the more likely they are
to catch new items. The clusters merge. They grow.
They form long, continuous runs of occupied data.
These runs are the traffic jams of the hash
table. When the table is ninety-nine percent full,
these runs can become massive. A new item might
have to travel thousands of slots to get to the
other side of the jam. Krapivin wondered what
would happen if the algorithm were less desperate.
What if it exercised a little self-control? He
developed a strategy that he eventually called
”Elastic Hashing”. The idea was counterintuitive.
When the algorithm tries to insert an item,
it probes a sequence of spots. It might find an
empty spot early in the sequence. But instead of
taking it, the algorithm might decide to skip
it. It might leave that spot empty on purpose.
Why would you leave a spot empty? Because
an empty spot acts like a firebreak. By
strategically leaving empty spaces in the middle
of dense regions, the algorithm prevents the
clusters from merging. It keeps the traffic jams
short. It sacrifices the immediate convenience
of the first available spot to preserve the
long-term health of the entire structure.
Krapivin started modeling his idea, working
through the logic on whiteboards and running
simulations. He wanted to see how performance
changed as the table filled up. He expected
some improvement, but he didn’t expect
to overturn the established rules. When
he looked at the worst-case scenarios
for Elastic Hashing, he saw that the
link between how full the table was and its
speed had changed. It wasn’t linear anymore.
It didn’t depend directly on x. Performance
now followed a logarithmic curve. The time
needed to insert an item grew with
the square of the logarithm of x.
In the world of large numbers, it is the
difference between a mountain and a molehill.
Let us return to the parking lot. Suppose
the lot is so full that x is one million.
There are a million occupied spots for every
one free spot. Under Yao’s linear prediction,
finding a spot would require, in the worst
case, one million checks. The system would
be unusable. Under Krapivin’s logarithmic model,
you calculate the logarithm of a million, which is
roughly twenty. You square twenty. You get four
hundred. One million versus four hundred. That
is the scale of the breakthrough. Krapivin
had designed a system that could be filled to
the absolute brim—99.999% full—and still function
with the snap and speed of a nearly empty system.
He realized he’d found something big.
He gathered his notes and went to see
Professor Farach-Colton. Farach-Colton,
a veteran of the algorithmic trenches,
was skeptical. Andrew had to be missing something
since the conjecture had stood out for 40 years.
The smartest minds in the world had looked at
it. If there were a simple trick like “skipping a
spot,” surely someone would have found it by now.
But Farach-Colton also knew Krapivin was different
and invited him to prove it. Farach-Colton
brought in a third mind, William Kuszmaul,
a theoretical computer scientist at
Carnegie Mellon University. Kuszmaul
is a prodigy who specializes in the
granular details of data structures.
Kuszmaul reviewed the manuscript and checked
the probability calculations. Then it hit him.
Kuszmaul told Krapivin, “You didn’t just come up
with a cool hash table. You’ve actually completely
wiped out a 40-year-old conjecture!”
The three researchers spent the next
year rigorously formalizing the mathematics.
They had to construct a bulletproof logical
argument showing why the log(x)^2 bound held
true for every possible case. In their paper,
“Optimal Bounds for Open Addressing
Without Reordering,” they presented
the proof. They showed that by giving up greedy
algorithms, you could avoid the linear slowdown.
But as they dug deeper, they uncovered a second
surprise, even more shocking than the first.
Yao’s 1985 paper had also established a limit
for the average time to find data. Yao proved
that for any greedy algorithm, the average
search time must grow logarithmically as the
table fills up. But Krapivin’s algorithm is
not greedy. Because it broke the greedy rule,
the team found it could also break the
average-time barrier. They discovered a
variant of their strategy where the average search
time does not grow at all. It remains constant.
This implies that you can have a memory bank that
is effectively one hundred percent full, and yet,
on average, you can find a piece of data just as
quickly as if the bank were empty. It all comes
down to managing disorder perfectly. In Krapivin’s
system, the algorithm manages the empty spaces so
aggressively that they are distributed with
perfect evenness. You are never far from a
hole. The “firebreaks” are spaced out so regularly
that the probe sequence never has to travel far to
find one. The team proved that this constant-time
performance was achievable with high probability.
The team did one last thing. They proved that they
could not go any further. Krapivin, Farach-Colton,
and Kuszmaul derived a “lower bound” for the
problem. They proved mathematically that for
this class of hash tables, the worst-case time
of log(x)^2 is the absolute floor. There is no
algorithm, discovered or undiscovered, that
can do better. Krapivin had hit the bedrock
of the problem and found the optimal solution.
The paper came out in January 2025 and made
waves in theoretical computer science. Guy
Blelloch, a professor at Carnegie Mellon,
called the result “beautiful”. Sepehr Assadi, a
professor at the University of Waterloo, pointed
out how lucky the timing was—they could have gone
another forty years believing in the linear wall.
Andrew Krapivin surprised himself when
he overturned a famous conjecture—one put
forward by a Turing Award winner! He says the
breakthrough came down to a few things: he was
”just having fun,” but he also credits the solid
support he got from his mentors and his family.
The implications of this work will take
years to fully filter through. Today,
computing is moving to the edge—putting
powerful AI on phones, watches,
and tiny sensors. In these devices,
memory is precious. Before this work,
engineers would leave twenty or thirty percent
of the memory empty just to avoid slowdowns.
Krapivin’s work suggests that we can run
these systems hotter. We can push them to
ninety-nine percent capacity and keep
them running at top speed. This could
lead to faster databases, more efficient
caches, and leaner systems. As for Andrew,
he finished his undergraduate studies in 2024
and is currently an incoming PhD student at
Carnegie Mellon University. He was named a
2024 Siebel Scholar. His paper was accepted
in the 65th Annual Symposium on Foundations of
Computer Science and covered in Quanta Magazine’s
Biggest Computer Science Breakthroughs for
2025. He has interned with Jane Street,
one of Wall Street’s most successful quantitative
hedge funds. For Andrew, the sky is the limit.