Punched-Card Encoding in Hollerith Tabulating Equipment

The 1880 census took the United States Census Bureau eight years to tabulate. The Constitution requires a count every decade, the population had grown from fewer than four million in 1790 to about 63 million in 1890, and estimates warned that the returns for 1890 might not be finished before the 1900 census began. The bottleneck was not counting people. It was answering many separate questions about the same people, each of which a tally sheet handles by sending a clerk through the returns again. Hollerith’s proposal, submitted to the contest the government ran for a solution, replaced the tally sheet with a record in which every hole position is a one-bit field, read by a circuit rather than by a person.

Forty-five columns of one-bit decisions

The census card was divided into fields: sections recording, among other things, the number of people in each household, how many were employed, and national origin. A field occupies a run of columns, and the pattern of holes within that run names one value of the attribute. Nothing on the card is self-describing. A deck carries no header and no column names; the meaning of a column exists only in the guide plate the operator worked from and in the wiring of the machine.

Density was the constraint that fixed the layout. The Tabulating Machine Company’s machines of the period had 45 columns and used round holes, and round-hole packing reached 45 columns before the 1928 introduction of the 80-column rectangular-hole card. The 80-column card holds 80 columns by 12 rows, which is 960 hole positions, and that total is the card’s entire capacity however the fields are drawn: widening one field by a column takes that column from another. Every decision about the schema is therefore a decision about which questions the deck can still answer, taken before a single card is punched. Punched cards were already in use for loom pattern control before this; what Hollerith supplied was the encoding of population attributes and the reading circuit that turned holes into counts.

A pin, a mercury cup, and one dial per position

The reading mechanism explains why the encoding is one bit per position rather than a compact code that the machine decodes. The card is pressed down over a bed of spring-loaded pins. Beneath each pin position sits a cup of mercury. The pins descend together. Where the card is solid the pin stops on the card; where a hole has been punched the pin passes through and enters the mercury, closing an electrical circuit, which advances a dial on the tabulator by one step. There is one dial position for every hole position on the card.

That arrangement is a counting machine with no instruction sequence. One pass over a deck produces, at the same time, the number of cards carrying a hole at each position. The parallelism runs across positions; the serialization runs across cards. Each card is examined once and all 45 comparisons happen at the same instant, in electromechanical form. The question being asked is not stored in the deck. It sits in the fixed mapping from pin to dial, which is why the field layout had to be agreed before the census schedules were printed.

Because a dial steps once per hole, the machine counts occurrences rather than summing quantities. A field that records household size yields, in a single pass, how many households had each size; the total number of persons in those households has to come from arithmetic on the counts, or from an adding mechanism, not from another reading of the same card. This is the same primitive that finite-difference tabulation used: add one, repeatedly, and let the arrangement of the additions carry the meaning. The difference engine added successive differences to produce the values of a polynomial; the tabulator adds one per hole and lets the field layout decide which of those sums is worth recording.

Sorting turns the deck into an index

Counting gives marginal totals. A question about two attributes at once, such as the number of married farmers over 40, needs the deck reorganized first, and that is the job of the sorter that stood beside the tabulator. The sorter was activated by a chosen combination of hole positions and dropped matching cards into compartments. A pass over the deck therefore partitions it by whatever pattern the sorter was set to detect, and the compartments can be read as a group.

Composition is the whole query language. To count married farmers over 40, the deck is partitioned on age, then on occupation, then on marital status, and the tabulator runs over the resulting buckets. The order of passes matters: a later pass has to be stable, preserving the order established by earlier ones, or the earlier grouping is destroyed inside each new compartment. Running the least significant field first and the most significant last yields a deck ordered by the composite key after one pass per field.

A two-field cross-tabulation costs a sort plus one run per bucket: partition on the first field, then count the second field inside each of the first field’s compartments. The bucket runs together touch every card once, so card handlings are about twice the deck size, but each run restarts the machine and reloads a compartment, which makes the number of setups grow with the number of buckets. The physical order of the deck was the only index the system had, and the same deck was sorted and re-sorted for each new table rather than queried in place.

# Simplified model of a 45-column card deck: each card is a tuple of booleans.
# A "pass" means every card in the deck is handled once by an operator.

def sort_pass(deck, col):
    """Partition on one column. Stability preserves earlier passes."""
    buckets = {}
    for card in deck:
        buckets.setdefault(card[col], []).append(card)
    return [buckets[k] for k in sorted(buckets)]      # one bucket per hole value

def tabulate(cards, col):
    """One dial per column: each hole at col steps that dial once."""
    return sum(1 for card in cards if card[col])

def two_field_table(deck, a, b):
    groups = sort_pass(deck, a)                       # 1 pass, N card feeds
    table = {i: tabulate(g, b) for i, g in enumerate(groups)}
    return table, 1 + len(groups)                     # setups, not card feeds

def composite_order(deck, key):
    """Least significant field first; each pass must be stable."""
    for col in reversed(key):
        deck = sort_pass(deck, col)
    return deck, len(key)                             # one pass per field

The model counts setups, not work: two_field_table reports one pass for the sort and one for each bucket run, while the number of card feeds is twice the deck size. composite_order shows the pass count growing with the width of the key rather than with the number of distinct values.

Why the card beat the tally sheet

The card was about the size of the paper currency in circulation in 1890, and that choice was not cosmetic. Currency drawers, bins and boxes already existed in offices that handled money, so a deck could be stored and handed out without new furniture. A card can also be read without being consumed, sorted without being rewritten, and checked by hand: a disputed total can be re-run, and a suspicious card pulled and compared against the schedule it was copied from. Paper that has been punched stays punched.

The price was paid at transcription. Data was transferred to cards with a pantograph punch: the operator aligned a pin over a hole in a guide plate and pressed hard to make a matching round hole in the stiff card, a slow process compared with the keyboard punches that came later. The Computer History Museum’s collection catalogue gives the 1890 figures as about 62 million cards, punched at about 700 cards per clerk per day and counted on 100 of the machines at about 1,000 cards per hour per machine. The same museum’s exhibit text gives the total as 60 million and describes an average operator handling about 7,000 cards a day, at least ten times faster than manual methods. The two totals differ by roughly two million cards; the daily figures describe different stages, punching at 700 cards and running at 7,000, and are consistent with each other if a working day ran about seven hours at 1,000 cards per hour.

Arithmetic on the catalogue’s own numbers shows where the time went. Sixty-two million cards at 700 per clerk per day is about 88,600 clerk-days of punching. The same 62 million at 1,000 cards per hour across 100 machines is 620 machine-hours per machine, roughly 26 days if the machines ran continuously. On those figures punching, not counting, dominated the elapsed time. Mechanising the count left the transcription of the schedules as the long pole, which is why the keyboard punch mattered more than a faster tabulator would have.

What the fixed format cannot express

Field width is the first limit. A field’s width is chosen when the schedule is designed, and a value that outgrows its field has nowhere to go: the card offers no position beyond the field’s last column. A question not anticipated in the layout cannot be answered from the deck at all, because the attribute was never punched, and re-punching the returns is the only repair. The medium is also write-once in practice. A wrong hole can be patched or the card replaced, but nothing on the card records that a correction happened, so accuracy rests on a separate verification step rather than on the record itself.

Sorting is destructive to order, and its failure mode is quiet. A pass that is not stable mixes groups inside compartments, and the tabulator then produces a table that is internally consistent and wrong, with no error signal. Every query that needs a different order pays a full pass per key field, and a deck that has been sorted for one report has to be sorted again for the next. The 45-column round-hole format gave way in 1928 to the 80-column rectangular-hole card with its 960 positions, and that physical format outlived the machines that first read it.

The company behind the equipment was founded, by museum accounts, in 1895, with some other accounts giving 1896; it merged with others in 1911 to form CTR, which became IBM, and Hollerith received $1.2 million for his shares. ENIAC’s function tables were switch banks read as constants during a computation: a fixed table consulted by the machine rather than computed by it. That is the same arrangement the card made with the deck, where the values are settled in advance and the machine’s only job is to combine them.