One pass, and no room

The keys worth counting before sampling

The sampling estimator for the third frequency moment spends most of its copies on keys that barely contribute to the answer. Finding the heavy keys first with a Count-Sketch, counting them, and sampling only the rest cuts the state for ten per cent from 5,260 words to about 1,500 on a moderately skewed stream, and from 23,598 to under a thousand on the stream built to be worst for the sampler. It costs five times more than it saves on a flat stream, where there is no heavy key to find. What decides it is how the frequencies are shaped, not how long the stream is, and the frequencies must be counted, not read off the sketch, because the sketch's error on a heavy key is cubed.

The moments past the second measured the estimator Alon, Matias and Szegedy wrote for the third and higher frequency moments, Fk=∑xfxkF_k = \sum_x f_x^k. Pick one position of the stream at random, count how often its key comes again from there to the end, call it rr, and report m(rk−(r−1)k)m(r^k - (r-1)^k), where mm is the stream’s length. Over the fxf_x positions of a key the reports telescope to mfxkm f_x^k, so the estimate is exactly unbiased on every stream. Its variance is a sum over the stream and can be computed rather than sampled. On a stream of 60,000 arrivals over 2,048 keys, ten per cent on F3F_3 took 103 copies on a flat stream and 2,630 on a moderately skewed one. On the stream built to be worst for it, 11,799 copies were needed.

Its closing section named where the copies go. On the moderately skewed stream most positions belong to keys whose reports are a tenth of the moment or less, and each of those copies contributes almost nothing. The remedy it proposed was the one the better algorithms use. Find the heavy keys with a sketch of the kind a sketch that is allowed to be under measured, count them nearly exactly, and sample only the remainder, where no key is heavy enough to dominate. It predicted that on the worst stream the heavy key would be found and removed, leaving singletons the sampler gets almost exactly. It asked at what size of stream the sketch’s own cost stops being worth paying.

The remedy works, and on the worst stream it works exactly as predicted. The answer to the question is not a size.

What a list of heavy keys could hold

Before any sketch is built, the frequencies themselves say how much there is to find. If a few keys hold most of F3F_3, then removing them leaves a remainder the sampler can handle. If they do not, a list of candidates has nothing to be a list of.

What there is to find: on a flat stream the 64 most frequent of 2,048 keys hold 9% of F3; at Zipf 0.5 the top 8 hold 71%, at Zipf 1 the single most frequent key holds 83%, and at Zipf 2 98%The share of F3 held by the K most frequent keys, exactly, on 60,000-arrival streams over 2,048 keys. Flat: 1 0%, 2 0%, 4 1%, 8 1%, 16 3%, 32 5%, 64 9%. Zipf 0.5: 1 32%, 2 46%, 4 59%, 8 71%, 16 80%, 32 86%, 64 91%. Zipf 1: 1 83%, 2 93%, 4 98%, 8 99%, 16 100%, 32 100%, 64 100%. Zipf 2: 1 98%, 2 100%, 4 100%, 8 100%, 16 100%, 32 100%, 64 100%. The horizontal axis is logarithmic.1248163264the most frequent keys (K)share of F30%25%50%75%100%flatZipf 0.5Zipf 1Zipf 260,000 arrivals, 2,048 keysexact
Fig. 1 The share of F3 held by the K most frequent of 2,048 keys, exactly, on 60,000-arrival streams. Flat: 9% in the top 64. Zipf 0.5: 32% in the top key, 71% in the top 8, 91% in the top 64. Zipf 1: 83% in the top key. Zipf 2: 98% in the top key.

On a flat stream the 64 most frequent keys hold 9% of F3F_3; at a Zipf exponent of one the single most frequent key holds 83% of it. Cubing magnifies every difference in frequency, so the third moment is more concentrated than the stream is. At the exponent the earlier page found hardest for the sampler, 0.5, the top key holds 32% and the top eight hold 71%. That exponent is hard for the sampler for the same reason it is promising here. The moment is concentrated enough that a few keys dominate it, but those keys are a small share of the stream’s positions, so a copy rarely lands on them. When one does, its report is enormous, and that is the variance. A copy that lands on a heavy key reports a number far larger than the moment it is estimating, and one such report in a hundred copies moves the whole average.

The flat stream shows the other side. Its moment is spread over two thousand keys in nearly equal shares, and no list short enough to be cheap holds a useful part of it. The sampler was already cheap there, 103 copies, because a flat stream’s positions all look alike. The skew a few counters cannot repair found the same division in a join estimate: a few counters fix the extreme skews and help nothing in the middle. The difference here is that the middle is where the list helps most.

The estimator, and two ways to read a candidate

The estimator makes one pass and keeps three things. A Count-Sketch of depth five and width ww sees every arrival. Beside it is a list of KK candidates: an arriving key whose sketch estimate beats the smallest candidate’s value takes its place. And cc copies of the sampling estimator run over the whole stream, because in one pass nobody knows which keys will turn out heavy. At the end, a copy whose key is on the list reports nothing, and the others report as before. The copies then estimate FLF_L, the moment of the keys not on the list, without bias however the list came out, and the heavy part is added from the list.

The heavy part can be read in two ways. Read off the sketch, a candidate’s frequency is the sketch’s estimate at the end of the stream. Counted from entry, a candidate is counted exactly from the moment it joins the list. Its frequency is then the sketch’s estimate on entry plus the arrivals since, so only the arrivals before it was listed carry the sketch’s error. The second costs one more word a candidate. It is the arrangement a count that is never under would have recommended for a key known to matter: once a key is worth asking about, stop asking the table and count it. State is counted in words: a sketch cell is one, a copy two (a key and its count), a candidate two or three.

Only the sketch’s hashing is random. Given the list a pass produces, the sampling part’s variance is exact, as it was on the earlier page. The error of the heavy part is averaged over sixteen sketch seeds, and the two add without a cross term, since the sampling part is unbiased given the list. The width and number of copies are then chosen to make the whole estimator’s relative standard deviation ten per cent in the fewest words.

On a Zipf 0.5 stream the plain sampler needs 5,260 words; reading each candidate's frequency off the sketch, the best hybrid needs 3,282 (4 candidates); counting each candidate exactly from the moment it is listed, 1,526 (16) — the sketch's error on a heavy key is raised to the third power, and counting removes most of itWords for 10% on F3 over a Zipf 0.5 stream of 60,000 arrivals and 2,048 keys, against the number of candidates K, each at its best sketch width. Sketch's estimate: K 1 4,838 (width 512), K 2 3,732 (width 512), K 4 3,282 (width 512), K 8 3,466 (width 512), K 16 5,234 (width 1024), K 32 5,234 (width 1024). Counted from entry: K 1 3,087 (width 128), K 2 1,844 (width 128), K 4 1,774 (width 256), K 8 1,530 (width 256), K 16 1,526 (width 256), K 32 2,686 (width 512). The plain sampler, dashed: 5,260 words (2,630 copies). Both axes are logarithmic.1248163210³10⁴candidates kept (K)words for 10% on F3sketch's estimatecounted from entryno sketchZipf 0.5, 16 sketch seedsdashed: the plain sampler
Fig. 2 Words for 10% on F3 on a Zipf 0.5 stream, against the number of candidates, each at its best sketch width. Read off the sketch: 4,838 words with one candidate, least at 3,282 with four. Counted from entry: 3,087 with one, least at 1,526 with sixteen. The plain sampler: 5,260 words (2,630 copies).

On the Zipf 0.5 stream, the best estimator reading candidates off the sketch needs 3,282 words; counting them from entry, 1,526. Both beat the plain sampler’s 5,260, but reading the sketch saves 38% of its words where counting saves 71%. The reason is the power. A key’s contribution to F3F_3 is f3f^3, and an error δ\delta in its estimated frequency becomes an error of about 3f2δ3f^2\delta in the contribution. That is three times the relative error, applied to a term that holds a third of the moment. A sketch accurate enough to give the heaviest key’s frequency to within 1% gives its contribution to within 3%, and the widths that achieve that are expensive. Counting from entry leaves only the first few arrivals of each heavy key to the sketch, when its count was small and its error mattered less.

The number of candidates behaves the same way in both. One candidate removes only the top key’s third of the moment, and the copies left must still cover a stream whose next few keys dominate what is left. Past a handful, each extra candidate removes a key that holds less, while the sketch must grow to tell it from its neighbours. Counted from entry, the bill is nearly flat from eight to sixteen candidates and rises after.

The bill, part by part

A single setting shows how the three parts of the state pull against one another. With four candidates counted from entry on the Zipf 0.5 stream, only the sketch’s width is left to choose.

The bill for a Zipf 0.5 stream with 4 candidates counted from entry, as the sketch widens: at widths 8 to 64 the heavy part alone is more than 10% out and no number of copies helps; the copies fall from 3,638 words at width 128 to 428 while the sketch grows from 640 to 20,480, and the whole is least, 1,774, at width 256Words of each part of the estimator for 10% on F3, Zipf 0.5, K = 4 candidates counted exactly from the moment they are listed, against the sketch's width (depth five). The whole: 8 none enough, 16 none enough, 32 none enough, 64 none enough, 128 4,290, 256 1,774, 512 3,012, 1024 5,560, 2048 10,680, 4096 20,920. Copies: 8 none enough, 16 none enough, 32 none enough, 64 none enough, 128 3,638, 256 482, 512 440, 1024 428, 2048 428, 4096 428. Sketch: 8 40, 16 80, 32 160, 64 320, 128 640, 256 1,280, 512 2,560, 1024 5,120, 2048 10,240, 4096 20,480. The heavy part's relative error from the sketch alone: 8 552%, 16 120%, 32 65%, 64 32%, 128 9%, 256 2%, 512 1%, 1024 0%, 2048 0%, 4096 0%. Both axes are logarithmic.816326412825651210242048409610010³10⁴sketch width (depth five)wordsthe wholecopiessketchZipf 0.5, K = 4, counted16 sketch seeds
Fig. 3 Each part of the state for 10% on F3, Zipf 0.5, four candidates counted from entry, against the sketch’s width. Below width 128 the heavy part alone is more than 10% out: 552% at width 8, 32% at 64. At 128 it is 9% out and the copies need 3,638 words; at 256 it is 2% out and they need 482. The whole is least, 1,774 words, at width 256.

Below a width of 128 no number of copies helps: the sketch’s error on the four candidates is already more than the whole estimator is allowed. At width 64 the heavy part alone is 32% out. Copies cannot repair that, because they estimate only the keys that are not on the list. At width 128 the heavy part is 9% out, which leaves almost nothing of the 10% for the sampling part, and 1,819 copies are needed to fit inside what remains. Doubling the width to 256 brings the heavy part to 2% and the copies to 241. Past that, the copies level off at 214 — what the remainder’s spread needs when the heavy part is nearly exact — and the sketch keeps doubling.

The narrowest usable sketch is set by the heavy part’s error, and the best one lies just past it. That is where the copies’ cliff flattens and before the sketch’s own cost takes over. The items that survive k counters found that a deterministic summary of kk counters beats a randomised sketch of the same state on the questions both are asked. The error that bounds a heavy-key estimate there, a share of the whole stream, would bound this one too if Misra–Gries replaced the sketch. The difference would be in the sign: its counts are never above the truth, so it would always under-report the heavy part.

Where it pays, and where it cannot

The sweep over the exponent puts the two estimators side by side on every shape of stream the earlier page measured.

Where finding the heavy keys pays: F3 to 10% on 60,000 arrivals over 2,048 keys takes the plain sampler 206 words on a flat stream, 5,260 at Zipf 0.5 and 1,882 at Zipf 1; with the heavy keys found and counted first, 985, 1,526 and 159 — the sketch costs more than it saves only where no key stands out, on a flat stream and at Zipf 0.25Words of state for a relative standard deviation of 10% on F3, against the Zipf exponent of the stream (0 is flat). Sample every position: 0 206, 0.25 676, 0.5 5,260, 0.75 3,930, 1 1,882, 1.5 632, 2 372. Heavy keys first: 0 985, 0.25 1,889, 0.5 1,526, 0.75 358, 1 159, 1.5 51, 2 45. For the hybrid, the best candidate count and sketch width at each exponent: 0 K 1, width 128, 171 copies; 0.25 K 1, width 128, 623 copies; 0.5 K 16, width 256, 99 copies; 0.75 K 8, width 64, 7 copies; 1 K 1, width 16, 38 copies; 1.5 K 1, width 8, 4 copies; 2 K 1, width 8, 1 copies. The vertical axis is logarithmic.00.250.50.7511.5210010³Zipf exponent of the streamwords for 10% on F3sample every positionheavy keys first60,000 arrivals, 2,048 keysa word: a key or a count
Fig. 4 Words for 10% on F3 against the Zipf exponent, 60,000 arrivals over 2,048 keys. Plain sampler: 206 words flat, 676 at 0.25, 5,260 at 0.5, 3,930 at 0.75, 1,882 at 1, 632 at 1.5, 372 at 2. Heavy keys first, counted: 985, 1,889, 1,526, 358, 159, 51, 45. Each hybrid at its own best number of candidates and width.

The list costs more than it saves on a flat stream (985 words against 206) and at Zipf 0.25 (1,889 against 676), and saves at every exponent from 0.5 upwards: 3.4 times at 0.5, eleven times at 0.75, twelve at 1, and eight at 2. The two curves cross between 0.25 and 0.5, which is where the top key’s share of F3F_3 rises from a few per cent to a third. Below the crossing, the sketch is paying to find keys that are not there. Even its smallest useful width, 128 cells, is 640 words, more than three times the plain sampler’s whole state on the flat stream.

The shape of the saving is the useful part. The plain sampler’s curve peaks in the middle, where the earlier page found every moment dearest, and the hybrid’s curve has no peak there. It falls from 0.25 onward and is below 200 words from Zipf 1. The heavy keys that made the middle expensive are exactly the ones the list catches, and what they leave behind is a remainder the sampler handles as cheaply as it handles a flat stream.

At the highly skewed end, Zipf 1.5 and 2, the plain sampler was already cheap: one key holds nearly the whole moment, and nearly every position belongs to it. The hybrid is cheaper still. One candidate counted from entry holds 98% of F3F_3 almost exactly, and one to four copies cover the rest. A sketch of width eight is enough to find a key that holds half the stream.

The stream built to be worst

The earlier page found the plain sampler’s worst stream of one simple shape. It is n−1n - 1 keys seen once and one key seen hh times, with hh near 1.7 n1/31.7\,n^{1/3}: frequent enough to dominate F3F_3, rare enough that a random position almost never lands on its first occurrence. On that stream the sampler needed a quarter of its published guarantee, and the guarantee grows as n2/3n^{2/3} for F3F_3.

On the stream built to be worst for the sampler — one key seen about 1.7·n^(1/3) times among n − 1 seen once — the plain sampler's words grow from 3,724 at 128 keys to 94,322 at 16,384, as n^0.67; with the heavy key found first the whole estimator needs 335 words at 128 keys and 1,325 at 16,384 counted from entry, and between 939 and 5,284 read off the sketch with no trend in nWords for 10% on F3 on a stream of n − 1 keys seen once and one key seen h times, h chosen to make the plain sampler's variance largest, against n. Sample every position: 128 3,724, 256 5,910, 512 9,372, 1,024 14,864, 2,048 23,598, 4,096 37,438, 8,192 59,424, 16,384 94,322. Sketch's estimate: 128 939, 256 1,869, 512 2,648, 1,024 5,284, 2,048 3,739, 4,096 2,644, 8,192 1,324, 16,384 939. Counted from entry: 128 335, 256 470, 512 244, 1,024 335, 2,048 940, 4,096 665, 8,192 1,325, 16,384 1,325. The heavy key's frequency: 128 9, 256 11, 512 14, 1,024 17, 2,048 22, 4,096 27, 8,192 35, 16,384 43. Hybrids keep one candidate and are sized over 32 sketch seeds; the best width at each size, counted: 66, 93, 47, 66, 187, 132, 264, 264. Both axes are logarithmic.1282565121,0242,0484,0968,19216,38410³10⁴10⁵keys in the stream (n)words for 10% on F3sample every positionsketch's estimatecounted from entryone heavy key among singletons32 sketch seeds
Fig. 5 Words for 10% on F3 on the one-heavy-key stream, from 128 to 16,384 keys. Plain sampler: 3,724 words at 128 keys to 94,322 at 16,384, growing as n to the power 0.67. Heavy key counted from entry: 335 to 1,325. Read off the sketch: between 939 and 5,284 with no trend. The heavy key is seen 9 times at 128 keys and 43 at 16,384.

At 2,048 keys the plain sampler needs 23,598 words and the hybrid, counting its one candidate from entry, needs 940 — and one copy. The prediction held exactly. The heavy key is found, and once it is removed the remainder is 2,047 keys seen once each. Every copy that lands on the remainder reports mm, so the sampling part’s variance comes only from the copies that land on the listed key and report nothing. That is a share of h/mh/m, about 1%. One copy gives the remainder’s moment to within about a tenth of itself, and the remainder is a sixth of F3F_3, so that is under 2% of the whole. The heavy key’s count, known almost exactly, carries the other five sixths.

Across sizes, the plain sampler grows as n0.67n^{0.67}, from 3,724 words at 128 keys to 94,322 at 16,384, exactly the guarantee’s exponent. The hybrid counted from entry grows fourfold across the same 128-fold range, from 335 to 1,325 words. The best sketch width wanders from 47 to 264 cells, because what sets it is whether a few of the 32 seeds collide the heavy key badly, and that is a matter of luck at every size. The prediction was a fall to n1−2/kn^{1-2/k}, which for F3F_3 is n1/3n^{1/3}. The measurement is consistent with that — the counted curve’s slope over the whole range is 0.28 — but the fluctuations are as large as the trend, and eight sizes do not settle it. Read off the sketch, the bill stays between 939 and 5,284 words with no trend at all. What is certain is the gap: 25 times at 2,048 keys and 71 at 16,384.

So the question the earlier page asked — at what size the sketch’s cost stops being worth paying — has a plain answer on this stream: at none measured. The sketch pays at 128 keys and pays more at every size above. On the flat stream it does not pay at 2,048 keys. It would not pay at any size either, because a flat stream’s plain sampler needs a fixed hundred copies whatever its length, and no sketch is that cheap. What decides whether the list is worth keeping is whether the moment is concentrated in a few keys, and that is a property of the stream’s frequencies, not of its length.

Where the measurement stops

One moment, one accuracy. Every number is for F3F_3 to a relative standard deviation of 10%. A higher moment concentrates further, so the list should pay from a lower exponent. But the heavy part’s error is multiplied by kk, so counting from entry matters more. A tighter accuracy squeezes the heavy part’s share of the error budget and pushes the narrowest usable sketch wider.

Words, not bits. A cell, a key and a count are each a word. The estimate that squares the stream priced the second moment’s sketch in bits, and the comparison there was between structures of one kind; here three kinds share a budget, and a word is the unit all three spend. The earlier page’s copies were about 27 bits at this size, and a sketch cell needs as many bits as the stream is long. Counting in bits would move the curves by constant factors and the crossing very little.

Sixteen sketch seeds, thirty-two on the worst stream. The sampling part is exact given the list. The heavy part’s mean square error is an average over seeds, dominated by the occasional seed that collides a heavy key in most rows. That is why the best widths wander, and why the estimator is sized on the mean square error rather than on the typical seed. A sizing on the typical seed would be smaller and would miss its accuracy on the unlucky ones.

The list is greedy. A key enters when its current estimate beats the smallest candidate’s, and a key evicted early loses its exact count. On the Zipf streams a heavy key is heavy from its first few arrivals and is rarely evicted. On a stream whose heavy keys arrive late — a key that becomes popular halfway through — the counted reading would carry more of the sketch’s error, and the entry estimate would matter more.

The hash families are the earlier pages’ pairwise ones. The independence an estimator spends found the tug-of-war estimator’s variance spends four-wise independence. A Count-Sketch’s median-of-rows guarantee needs only pairwise, and nothing here depends on more.

Still open: a list whose length the stream chooses

Every estimator here fixes its number of candidates before the stream begins, and the best number moved from one on the steep streams to sixteen at Zipf 0.5. It moved because the right list is the one that removes every key heavy enough to dominate what is left, and how many keys that is depends on the frequencies. A system that knew its streams’ exponent could choose KK in advance. One that did not would provision for the worst and pay for candidates it never used on the steep streams.

The measurement that follows lets the stream decide. The list is kept long, and at the end a candidate is counted in the heavy part only if its contribution exceeds a stated share of the estimated moment; the rest are returned to the sampled part by letting their copies report. It asks whether one threshold, stated as a share of F3F_3, reaches within a few per cent of the best fixed KK on every exponent. The prediction is that it does, because the best KK at each exponent is the list that removes the keys whose reports make the sampler’s variance, and those are the keys with the largest shares of the moment — which is what a threshold on the share selects, stated once for every stream. It could fail on the flat stream, where the list’s cost is in the sketch that must be wide enough to rank the candidates at all. If it does, the threshold would need to govern the sketch’s width as well as the list’s length — the choice the pass that was never a parameter made with a second pass, here made with nothing but the counts already held.

Named alongside this one

Essays reaching for the same objects. Nobody chose these; they are what the concept index makes visible.

The objects this essay names

Each one links to every other essay that touches it.

Count-SketchHeavy hitterHonest limitRelative errorSamplingState bitsStreaming algorithmUnbiased estimatorVarianceZipf distribution