Egyptian and Russian Peasant Multiplication: Doubling and Binary

Egyptian multiplication works by doubling one number again and again, then adding the doubled rows whose row labels sum to the other number. Russian peasant multiplication is the same idea run from the other side: halve one number, double the other, and add the rows where the halved number is odd. Both are binary arithmetic, and processors still multiply this way.

You need no times tables. If you can double and add, you can multiply, divide and work with fractions the way an Egyptian scribe did more than 3,500 years ago. This post shows the scribes' layout: a doubling column, ticks against the rows you need, and a final sum. We then run the series' fixed problem set (98 x 97, 47 x 53, 386 x 524, 85², √7,744, 7,429 ÷ 37 and 1/19) through Egyptian doubling, through Russian peasant halving, and through the binary view a computer uses, and count the steps honestly.

Every number in this post was computed and checked with Python, and the script is in the walkthrough near the end. Historical facts come from MacTutor at the University of St Andrews and the other sources listed at the bottom; where they disagree, we say so.

Key takeaways

• The source. The Rhind Mathematical Papyrus, copied by the scribe Ahmes from an older text, dated about 1650 BCE by MacTutor and about 1550 BCE by other references.
• The method. Double one factor row by row, tick the rows whose labels (1, 2, 4, 8 and so on) add up to the other factor, and add the ticked rows. It works because every whole number is a sum of distinct powers of two.
• Russian peasant multiplication halves one factor, doubles the other and keeps the rows where the halved number is odd. The odd rows are the 1 bits of that number in binary.
• Pick the factor with fewer 1 bits. 386 x 524 needs 8 doublings and only 2 additions, because 386 = 256 + 128 + 2.
• Division runs the table backwards: 7,429 ÷ 37 = 200 remainder 29, and the scribe would write 29/37 as 2/3 + 1/9 + 1/222 + 1/666.
• Roots and decimals are not native. √7,744 = 88 and 1/19 = 0.052631578947368421 (repeating) can be reached with doubling tables, but the method was not built for them.
• Computers multiply by shift and add, which is this method in base 2, and raise numbers to powers by the same doubling idea.
• Speed, honestly. With the times tables memorised, the school method writes fewer digits. Doubling wins without tables and for multipliers with few 1 bits. We found no measured record for it, so we claim nothing beyond step counts.

The problem set at a glance

Where the method comes from: the Rhind papyrus

What the papyrus is

The Rhind Mathematical Papyrus is the richest single source we have for Egyptian arithmetic. MacTutor describes it as a scroll about 6 metres long and a third of a metre wide, written by the scribe Ahmes, who states that he is copying a document about 200 years older. The Scottish antiquarian Alexander Henry Rhind bought it in Luxor in 1858, which is why it carries his name. Most of it is in the British Museum (catalogued as BM 10057 and 10058), and fragments bought separately in Luxor in the 1860s are now in the Brooklyn Museum. MacTutor notes a growing habit of calling it the Ahmes papyrus, after the scribe rather than the buyer.

The date needs care, because the sources disagree. MacTutor dates the copy to about 1650 BCE and gives Ahmes approximate life dates of 1680 to 1620 BCE. Other references, following the Egyptological literature, date it to about 1550 BCE, because the colophon names Year 33 of the Hyksos king Apepi (Apophis) and says the original was made under Amenemhat III of the 12th Dynasty.

Both agree that the content is older than the copy. "About 1650 to 1550 BCE, a copy of an older text" is the safe summary.

The papyrus opens by promising "accurate reckoning" and then works through tables and problems. MacTutor counts 87 problems: arithmetic with fractions, sharing barley among workers, the volumes of granaries, the area of a round field (Problem 50, which takes away a ninth of the diameter and squares the rest), and simple linear equations solved by false position. Most of the multiplying and dividing inside those problems uses the doubling method.

Egyptian numerals, and why doubling suited them

The Egyptians wrote numbers additively. Hieroglyphic numerals had one symbol for 1, another for 10, another for 100, and so on up to a million, and a number was written by repeating each symbol as often as needed. MacTutor gives the example of 276, which needs fifteen symbols: two hundreds, seven tens and six units. The hieratic script used on papyrus was more compact, with separate signs for 1 to 9, 10 to 90, 100 to 900 and so on, but it was still not a place value system: MacTutor points out that hieratic numerals could be written in any order.

That matters for multiplication. Our school method depends on place value and a memorised 9 x 9 table. An additive system has neither, but it makes two operations very easy:

• Adding: put the symbols together, and replace any ten copies of a symbol with one symbol of the next size.
• Doubling: write every symbol twice, then regroup in the same way.

Here is 386 doubled twice, written as counts of hundreds, tens and units, the way an additive scribe would see it.

No multiplication fact was used. A system built on doubling and adding needs nothing else, and the Egyptians built multiplication, division and fraction arithmetic entirely on those two operations.

Two other Middle Kingdom documents show the same arithmetic in use: the Moscow Mathematical Papyrus, with 25 problems according to MacTutor, and the Berlin Papyrus 6619, which comes up again under problem 5.

How Egyptian multiplication works

The rule fits in four lines.

1. Write two columns. Put 1 at the top of the left column and one of your factors at the top of the right column.
2. Double both columns, row by row, until the next left-hand entry would be larger than the other factor.
3. Tick the rows whose left-hand entries add up to the other factor. Start from the bottom row and work up: take a row if it still fits in what is left.
4. Add the right-hand entries of the ticked rows. That sum is the product.

MacTutor's worked example from the papyrus tradition is 41 x 59. Double 59:

The next row would be 64, which is more than 41, so stop. Now pick rows that sum to 41: 32 fits (9 left), 16 does not fit, 8 fits (1 left), 4 and 2 do not, 1 fits (0 left). So 41 = 32 + 8 + 1, and the product is 1,888 + 472 + 59 = 2,419.

Why it always works

Two facts make the method complete:

• Every whole number is a sum of distinct powers of two, in exactly one way. That is what binary notation says. 41 is 101001 in binary, which reads as 32 + 8 + 1.
• Multiplication distributes over addition. 41 x 59 = (32 + 8 + 1) x 59 = 32 x 59 + 8 x 59 + 1 x 59, and each of those products is already sitting in the doubling column.

So the scribe never needs a product that is not on the table. The greedy pick from the bottom also always works, because each power of two is larger than the sum of all the smaller ones (32 is more than 16 + 8 + 4 + 2 + 1 = 31), so if a row fits, you must take it.

We have no evidence that the scribes thought of this as binary. The binary reading is ours, and it is useful because it explains both why the method works and how much work it takes.

Russian peasant multiplication: halve and double

Russian peasant multiplication reaches the same rows from the other direction. Instead of building up powers of two in a left column and then picking from them, you halve one factor repeatedly and let odd and even do the picking.

1. Write the two factors side by side.
2. Halve the left number, dropping any remainder, and double the right number. Write them on the next row.
3. Repeat until the left number is 1.
4. Strike out every row where the left number is even.
5. Add what is left in the right column.

Here is 41 x 59 again.

Kept rows: 59 + 472 + 1,888 = 2,419. The same three rows as the Egyptian table.

Why the odd rows are the right ones

Halving with the remainder dropped is the same as shifting a binary number one place to the right. Whether the current number is odd tells you its lowest binary digit. So reading odd and even from top to bottom reads the binary digits of 41 from the lowest up:

Read the digit column from bottom to top and you get 101001, which is 41 in binary. The odd rows are the rows whose powers of two make up 41. Egyptian doubling finds those powers by subtraction from the top; peasant halving finds them by parity from the bottom. The arithmetic left to do afterwards is identical.

About the name

Reference works call it Russian, peasant, Ethiopian or Egyptian multiplication; the Wikipedia article on ancient Egyptian multiplication lists all four. We found no primary source for where the "Russian peasant" label started, so we treat it as a label, not as history.

Problem 1: 98 x 97

Egyptian layout

Either factor can be doubled. Decompose the one with fewer 1 bits, because each 1 bit costs an addition. 97 is 1100001 in binary (64 + 32 + 1) and 98 is 1100010 (64 + 32 + 2). Both have three 1 bits, so either way is three ticks and two additions. Here we double 98 and decompose 97.

Pick from the bottom: 64 fits in 97 (33 left), 32 fits (1 left), 16, 8, 4 and 2 do not, 1 fits (0 left).

98 x 97 = 9,506. Work done: 6 doublings and 2 additions.

Russian peasant layout

Seven rows, six halvings, six doublings, two additions. The running total column is how you would do it in your head: you never need to remember the struck rows.

How it compares

The Vedic Nikhilam method in the Indian and Vedic mathematics post does 98 x 97 in four operations (deficits 2 and 3, 98 − 3 = 95, 2 x 3 = 06). Doubling cannot compete here, because it sees only binary digits, not the closeness to 100. That is its trade everywhere: it treats every number the same, so it never fails and never gets a lucky shortcut.

Problem 2: 47 x 53

This is the problem where the choice of factor matters most.

So double 47 and decompose 53.

Egyptian layout, decomposing 53

53 = 32 + 16 + 4 + 1. Running sum: 47, then 47 + 188 = 235, then 235 + 752 = 987, then 987 + 1,504 = 2,491.

47 x 53 = 2,491. Work done: 5 doublings and 3 additions.

If you double 53 and decompose 47 = 32 + 8 + 4 + 2 + 1 instead, the ticked rows are 53, 106, 212, 424 and 1,696, with running sums 53, 159, 371, 795 and 2,491. Same answer, one more addition.

A modern refinement cuts this further by allowing subtraction. 47 = 48 − 1 = 32 + 16 − 1, so 47 x 53 = 1,696 + 848 − 53 = 2,491, which is two operations after the table. Modern hardware uses the same idea, as we will see in the section on Booth recoding.

Russian peasant layout, halving 53

And halving 47 instead keeps five rows: 47 (53), 23 (106), 11 (212), 5 (424) and 1 (1,696), with 2 (848) struck. Running totals 53, 159, 371, 795, 2,491.

How it compares

The fastest route for 47 x 53 is the difference of squares, 50² − 3² = 2,500 − 9 = 2,491. The Chinese counting board and the soroban add the partial products 2,000, 120, 350 and 21 with no carries. Doubling needs more rows than either, but no multiplication facts.

Problem 3: 386 x 524

This is the biggest multiplication in the set, and the one where doubling looks best, because both factors happen to have only three 1 bits.

Egyptian layout, decomposing 386

Doubling 524 needs a row for 256, so eight doublings.

Pick from the bottom: 256 fits in 386 (130 left), 128 fits (2 left), 64 down to 4 do not, 2 fits (0 left).

386 x 524 = 202,264. Work done: 8 doublings and 2 additions.

Decomposing 524 = 512 + 8 + 4 instead needs nine doublings of 386, ticking 1,544, 3,088 and 197,632, which also sum to 202,264. When the choices tie on additions, decompose the smaller number: it needs fewer doublings.

Russian peasant layout, halving 386

Nine rows, eight halvings, eight doublings, two additions.

The same problem as a computer sees it

A binary multiplier does exactly the Egyptian table, except that doubling a binary number is free: you shift it one place left. Each 1 bit of 386 selects a shifted copy of 524.

Sum: 202,264, which is 110001011000011000 in binary. Put the doubling column next to this table and they are the same rows.

How it compares

Every method in the comparison post needs nine single-digit products for 386 x 524. Doubling needs none, but eight multi-digit doublings instead. The school method writes fewer digits (11 in its three partial products, against 56 in the doubling table with labels), but every doubling row can be checked on its own, since it is exactly twice the row above.

Problem 4: 85²

Squaring is just multiplication of a number by itself, and doubling treats it no differently. 85 is 1010101 in binary: 64 + 16 + 4 + 1.

Egyptian layout

Running sum: 85, 85 + 340 = 425, 425 + 1,360 = 1,785, 1,785 + 5,440 = 7,225.

85² = 7,225. Work done: 6 doublings and 3 additions.

Russian peasant layout

How it compares

85² is the classic case for the Vedic Ekādhikena Pūrvena rule (8 x 9 = 72, then append 25): two operations against nine for doubling. Doubling knows nothing about numbers ending in 5; it sees the alternating pattern 1010101, which is why there are four ticks.

Problem 5: √7,744

Why the method cannot do this directly

Doubling multiplies and divides. It has no built-in step for undoing a square. The Egyptians did need square roots. The Berlin Papyrus 6619 asks for two squares whose areas add up to a square of 100, with the side of one equal to 1/2 + 1/4 of the side of the other. In modern terms that is (3/4 y)² + y² = 100, with y = 8 and x = 6, and solving it needs the roots of 100 and of 25/16. Both are perfect squares. In the descriptions we read, the roots appear as known values, and we found no surviving Egyptian text that sets out a general procedure for extracting one. Tables of squares or trial and error are plausible, but that is a guess, not a documented fact.

So the honest answer is: Egyptian and peasant multiplication cannot extract √7,744 on their own. They can check a candidate root fast, and with a little organisation they can search for it.

Searching by doubled squares

Build the root one power of two at a time, largest first. Keep a candidate r and its square. To test adding b, use (r + b)² = r² + 2rb + b², which needs only doubling and adding.

√7,744 = 88. Four trials. If 7,744 had not been a perfect square, the search would continue through 4, 2 and 1 and finish with the whole number part of the root. Running all seven bits here would also try 92, 90 and 89, whose squares (8,464, 8,100 and 7,921) are all larger, confirming 88.

Checking 88 x 88 by doubling

88 is 1011000 in binary: 64 + 16 + 8.

704 + 1,408 + 5,632 = 7,744. Confirmed.

The computer version

Integer square root routines often run this same search in binary, with shifts in place of doublings. 7,744 is 1111001000000 in binary (13 bits), so the root has at most 7 bits and needs at most seven trials. The Chinese digit by digit extraction in the Chinese mathematics post works a decimal digit at a time, 8 then 88, in two rounds. Base 10 takes fewer rounds; base 2 makes each round trivial.

Problem 6: 7,429 ÷ 37

Division is where the Egyptian method shines, because it is the multiplication table read backwards. The question "7,429 divided by 37" becomes "how many 37s make 7,429?", and the doubling column of 37 answers it.

Step 1: double the divisor

Keep doubling 37 until the next row would pass 7,429.

The next row would be 256 against 9,472, which is more than 7,429, so stop. That is 7 doublings.

Step 2: take rows from the bottom

Subtract each row that still fits, and tick its label.

7,429 ÷ 37 = 200 remainder 29. The ticked labels 128 + 64 + 8 = 200 are the quotient. Work done: 7 doublings, 3 subtractions and 2 additions of labels.

MacTutor's own example from the papyrus tradition works the same way: 1,495 ÷ 65 uses rows 65, 130, 260, 520 and 1,040, and 1,040 + 260 + 130 + 65 = 1,495 gives the ticked labels 16 + 4 + 2 + 1 = 23. For 1,500 ÷ 65, the same rows leave 5 over, and since 5 is a thirteenth of 65 the scribe writes the answer as 23 and 1/13.

Step 3: the remainder as unit fractions

A scribe would not stop at "remainder 29". The answer had to be a number, and Egyptian numbers below 1 were written as sums of distinct unit fractions (fractions with numerator 1), plus the special fraction 2/3. MacTutor notes 2/3 as the frequent exception and 3/4 as a rarer one. So the question becomes: which parts of 37 add up to 29?

Work it as a scribe would, taking a large part first and then filling the gap.

The last two lines come from the papyrus's own rule. Problem 61 of the Rhind papyrus gives 2/(3n) = 1/(2n) + 1/(6n). The gap of 2/9 as a share of 37 is 2/333, and 333 = 3 x 111, so 2/333 = 1/222 + 1/666.

So in Egyptian form:

7,429 ÷ 37 = 200 + 2/3 + 1/9 + 1/222 + 1/666.

Check it the other way: 24 2/3 + 4 1/9 + 1/6 + 1/18 = 28 + (12 + 2 + 3 + 1)/18 = 28 + 1 = 29. In modern decimals, 29/37 = 0.783783... because 37 x 27 = 999, so 29/37 = 783/999 and the three digits 783 repeat. The full answer is 200.783 with 783 repeating.

There are other valid expansions. The greedy method that Fibonacci described in the Liber Abaci (1202), and which J. J. Sylvester studied in 1880, always takes the largest unit fraction that fits. For 29/37 it gives 1/2 + 1/4 + 1/30 + 1/2,220. Both expansions are correct. The scribe's version uses 2/3, which was the Egyptians' favourite first step.

Why this is fast

There is no guessing of trial digits, which is where long division usually goes wrong: each subtraction either fits or does not. A computer's restoring division is the same procedure in binary.

Problem 7: 1/19

For a scribe, 1/19 is already finished

To an Egyptian scribe, 1/19 was not a problem at all. It is a unit fraction, so it is already in final form. The question the scribes did need to answer was what happens when you double it, because doubling is how they multiplied. That is exactly what the 2/n table at the front of the Rhind papyrus is for:

2/19 = 1/12 + 1/76 + 1/114.

Check: the common denominator is 228, and 19 + 3 + 2 = 24, so the sum is 24/228 = 2/19. The greedy method would instead give 1/10 + 1/190, which is shorter. Ahmes's choice is longer but has smaller and more convenient denominators, which matches the pattern of the whole table, described below.

A decimal expansion by doubling

The method has no decimals, but long division into base 10 is just repeated division, so the doubling table of 19 can do it. You need only four rows, because each step divides a number below 190 by 19, and the quotient digit is at most 9.

At each step, multiply the remainder by 10, find the largest combination of rows that fits (that combination's labels add up to the next digit), and subtract.

The remainder is back to 1 after 18 steps, so the digits repeat from there:

1/19 = 0.052631578947368421 052631578947368421 ...

The period is 18 digits because 10¹⁸ is the first power of 10 that leaves remainder 1 when divided by 19. Notice that the first nine digits (052631578) and the last nine (947368421) add up digit by digit to 9. Once you know that, you can stop at step 9 and write the second half by subtracting each digit from 9. The Vedic post gets the same digits from the right with its Ekādhikena Pūrvena rule, multiplying by 2 at each step. That rule is doubling too, which is a nice coincidence between the two traditions.

The binary expansion is pure doubling

In base 2 the method becomes even simpler, because each step multiplies the remainder by 2, not by 10. Double the remainder; if it reaches 19, write a 1 and subtract 19, otherwise write a 0.

So 1/19 in binary is 0.000011010111100101 repeating, again with period 18. As a check, the 18-bit block 000011010111100101 is the number 13,797, and 13,797 x 19 = 262,143 = 2¹⁸ − 1, exactly as a repeating block must satisfy. Every step here is a doubling and a compare, which is the Egyptian method's whole toolkit.

Egyptian fractions and the 2/n table

Why only unit fractions

Egyptian arithmetic wrote every fraction below 1 as a sum of distinct unit fractions: 1/2, 1/3, 1/4 and so on, each used at most once. MacTutor notes two exceptions, 2/3, which was used often and had its own sign, and 3/4, which was used less often. In hieroglyphs a unit fraction was written with the sign for "part" (a mouth) placed over the number. So 3/5 could not be written as such. A scribe wrote it as 1/2 + 1/10.

That creates a problem for a doubling method. Twice 1/4 is 1/2, but twice 1/5 is 1/5 + 1/5, which repeats a fraction. Since the method doubles every row, scribes needed a ready answer for "what is twice 1/n?" whenever n is odd.

The 2/n table

The Rhind papyrus opens with exactly that answer: a table expressing 2/n as distinct unit fractions for every odd n from 3 to 101. The Wikipedia transcription of the table counts 50 expansions, spread over nine sheets of the papyrus. Here is a sample, each line checked with exact fractions in Python.

MacTutor calls it remarkable that the table contains no errors, and notes that the few errors elsewhere in the papyrus look like calculation slips carried forward, not copying mistakes.

How were the expansions chosen?

Nobody knows for certain; historians have proposed several techniques. Some patterns are clear:

• Multiples of 3. Problem 61 states the rule 2/(3n) = 1/(2n) + 1/(6n). Every 2/n with n divisible by 3 follows it: 2/9 = 1/6 + 1/18, 2/15 = 1/10 + 1/30, 2/21 = 1/14 + 1/42.
• Convenient first terms. The first denominator often has many divisors, such as 12, 24, 30, 40 or 60. 2/19 starts with 1/12, not the greedy 1/10.
• Short expansions. No line uses more than four terms.
• The last line is a formula. 2/101 = 1/101 + 1/202 + 1/303 + 1/606 is the general identity 2/n = 1/n + 1/(2n) + 1/(3n) + 1/(6n), which works for any n.

Compare the greedy expansions: 2/19 would be 1/10 + 1/190, 2/37 would be 1/19 + 1/703, and 2/97 would be 1/49 + 1/4,753. The scribe's versions trade an extra term for smaller denominators that are easier to work with later.

Egyptian fractions after Egypt

Egyptian fractions outlived Egypt by a long way. Fibonacci's Liber Abaci (1202) uses them throughout, gives a list of conversion methods, and as a last resort describes the greedy algorithm. Sylvester rediscovered the greedy method in 1880, and it is now often called the Fibonacci to Sylvester expansion.

From papyrus to processor: shift and add

Multiplication

Doubling a binary number means shifting every bit one place left and putting a 0 on the right. That costs essentially nothing in hardware. So binary multiplication is the Egyptian method with the doubling made free:

1. Look at the lowest bit of the multiplier.
2. If it is 1, add the multiplicand to a running total.
3. Shift the multiplicand one place left (double it) and the multiplier one place right (halve it, dropping the remainder).
4. Repeat until the multiplier is 0.

Steps 1 to 4 are Russian peasant multiplication, word for word. The Wikipedia article on binary multipliers notes that until the late 1970s most minicomputers had no multiply instruction, so programmers wrote multiply routines that shift and accumulate, exactly as above. It is still true on some small chips today. Microchip's AVR instruction set manual describes MUL as an 8-bit by 8-bit multiply into a 16-bit result, and states that "this instruction is not available on all devices"; its summary table marks MUL as not available on the reduced AVR core. On those parts, a compiler emits a shift and add loop.

Here is 47 x 53 as a processor without a multiplier would run it, halving 47 and doubling 53.

That is the peasant table for 47 x 53 from Problem 2, with the left column written in binary.

How fast hardware improves on it

A modern processor with a hardware multiplier does not loop. It forms all the partial products at once (one shifted copy of the multiplicand per 1 bit, exactly the ticked rows) and adds them in a tree of adders. Two classic ideas make this faster, both still taught under their inventors' names:

• Booth recoding. Andrew Donald Booth devised his signed multiplication technique in 1950 at Birkbeck College, London, and published it in 1951. Its effect is to replace a run of 1 bits with one subtraction and one addition. For 47 = 101111, the run 1111 (15) becomes 16 − 1, so 47 = 32 + 16 − 1 and 47 x 53 = 1,696 + 848 − 53 = 2,491: two operations instead of four. The idea is a scribe's trick formalised: if a number is just below a convenient row, subtract.
• Wallace trees. Chris Wallace's 1964 paper "A suggestion for a fast multiplier" showed how to add many partial products in a logarithmic number of stages instead of one after another.

So the partial products a processor adds are still the Egyptian ticked rows. Hardware just adds them in parallel.

Division

Binary long division, called restoring division in hardware texts, is Egyptian division run one row at a time. Shift the divisor up to its largest copy that fits, then walk down: compare, subtract if it fits and write a 1 in the quotient, otherwise write a 0. The quotient bits are the ticked labels. 7,429 ÷ 37 gives the bits for 128, 64 and 8, which is 11001000 in binary, or 200.

Powers: exponentiation by squaring

Replace "double" with "square" and "add" with "multiply" and the same table computes powers. To find 3¹³, write 13 = 8 + 4 + 1 (1101 in binary), and square repeatedly:

3¹³ = 6,561 x 81 x 3 = 1,594,323: three squarings and two multiplications instead of twelve multiplications. This is how computers raise numbers to large powers, including the modular powers at the heart of public key cryptography. CPython's own source code for integer powers says it uses "left-to-right binary exponentiation", citing Algorithm 14.79 of the Handbook of Applied Cryptography, and switches to a windowed version only for very large exponents.

When the doubling idea is not used

For large integers, software moves on. CPython's source says it uses the school algorithm unless both numbers have more than 70 internal digits (its KARATSUBA_CUTOFF), and Karatsuba multiplication above that, which needs three half-size products instead of four.

Is it fast? Counting the steps honestly

Speed has to be shown, not asserted, so here is the count for the four multiplications, using the cheaper choice of factor each time.

"Digits doubled" counts every digit you double while building the table, which is the method's main cost. "Mental load" counts the digits of the three numbers you carry in peasant multiplication: the halved number, the doubled number and the running total.

Doubling is fast when you have no times tables (a beginner, or a machine without a multiplier), when the multiplier has few 1 bits, and for division, where it removes the trial-digit guessing of long division. It is slow for multipliers with many 1 bits (47 = 101111), for special cases that other methods exploit (98 x 97, 85², 47 x 53 = 50² − 3²) and for large numbers, where the table grows long.

On measured speed, we have nothing to cite. The Mental Calculation World Cup, held since 2004, publishes results at recordholders.org, but we found no record or peer-reviewed study that measures doubling against other methods, so we make no claim beyond the counts above.

Error checks

The doubling method has unusually good built-in checks, because every row has a fixed relationship to its neighbours.

Casting out nines is a checksum, as the comparison post explains. It misses two swapped digits, because swapping does not change a digit sum. The row check is stronger here: it catches a doubling slip at the row where it happens.

A four-week practice plan

Fifteen minutes a day is enough.

• Week 1: double two- and three-digit numbers aloud five times in a row (37, 74, 148, 296, 592), and write numbers up to 127 in binary.
• Week 2: five Egyptian multiplications a day on paper. Count the 1 bits of both factors first and decompose the one with fewer. Do the label check every time.
• Week 3: five peasant multiplications in your head, keeping only the running total and the current pair, then five divisions by doubling with remainders as unit fractions.
• Week 4: mixed sets that include special cases. Decide before starting whether doubling or a shortcut from another tradition is cheaper.

Walkthrough: reproduce every number in Python

Every table in this post can be regenerated with the short script below. It needs only the Python standard library. Run it with python3 egyptian.py.

from fractions import Fraction

def egyptian_multiply(a, b):
    """Double b; tick the rows whose labels sum to a."""
    rows = []
    label, value = 1, b
    while label <= a:
        rows.append((label, value))
        label, value = label * 2, value * 2
    left, total, ticked = a, 0, []
    for label, value in reversed(rows):
        if label <= left:
            left -= label
            total += value
            ticked.append(label)
    return total, rows, sorted(ticked)

def peasant_multiply(a, b):
    """Halve a, double b, keep rows where a is odd."""
    total, rows = 0, []
    while a >= 1:
        keep = a % 2 == 1
        if keep:
            total += b
        rows.append((a, b, keep, total))
        a, b = a // 2, b * 2
    return total, rows

def egyptian_divide(n, d):
    """Double d; subtract rows from the bottom; labels give the quotient."""
    rows = []
    label, value = 1, d
    while value <= n:
        rows.append((label, value))
        label, value = label * 2, value * 2
    q, r = 0, n
    for label, value in reversed(rows):
        if value <= r:
            r -= value
            q += label
    return q, r

def greedy_unit_fractions(fr):
    out = []
    while fr > 0:
        den = -(-fr.denominator // fr.numerator)  # ceiling
        out.append(den)
        fr -= Fraction(1, den)
    return out

def bitwise_isqrt(n):
    r = 0
    for b in [1 << k for k in range(n.bit_length() // 2, -1, -1)]:
        if (r + b) * (r + b) <= n:
            r += b
    return r

def digits_by_doubling_table(d, count, base=10):
    r, out = 1, []
    for _ in range(count):
        r *= base
        out.append(r // d)
        r %= d
    return "".join(map(str, out))

for a, b in [(97, 98), (53, 47), (386, 524), (85, 85), (41, 59)]:
    total, rows, ticked = egyptian_multiply(a, b)
    assert total == a * b == peasant_multiply(a, b)[0]
    print(f"{a} x {b} = {total}; doublings {len(rows) - 1}; ticked {ticked}")

print("7429 / 37 ->", egyptian_divide(7429, 37))
assert egyptian_divide(7429, 37) == divmod(7429, 37)
scribe = [Fraction(2, 3), Fraction(1, 9), Fraction(1, 222), Fraction(1, 666)]
assert sum(scribe) == Fraction(29, 37)
print("greedy 29/37:", greedy_unit_fractions(Fraction(29, 37)))
assert Fraction(1, 12) + Fraction(1, 76) + Fraction(1, 114) == Fraction(2, 19)
print("isqrt(7744) =", bitwise_isqrt(7744))
print("1/19 decimal:", digits_by_doubling_table(19, 18))
print("1/19 binary: ", digits_by_doubling_table(19, 18, base=2))
print("3**13 =", pow(3, 13))

The output, exactly as it ran for this post:

97 x 98 = 9506; doublings 6; ticked [1, 32, 64]
53 x 47 = 2491; doublings 5; ticked [1, 4, 16, 32]
386 x 524 = 202264; doublings 8; ticked [2, 128, 256]
85 x 85 = 7225; doublings 6; ticked [1, 4, 16, 64]
41 x 59 = 2419; doublings 5; ticked [1, 8, 32]
7429 / 37 -> (200, 29)
greedy 29/37: [2, 4, 30, 2220]
isqrt(7744) = 88
1/19 decimal: 052631578947368421
1/19 binary:  000011010111100101
3**13 = 1594323

The Fraction type keeps every unit fraction exact, so the asserts prove the scribe's 29/37 expansion and the papyrus's 2/19 line rather than approximating them.

Common mistakes

• Decomposing the wrong factor. Count the 1 bits first. 47 x 53 costs one more addition if you decompose 47, and 386 x 524 costs one more doubling if you decompose 524.
• Stopping the table one row early. Keep doubling until the next label would exceed the multiplier. For 97 you need the 64 row; for 7,429 ÷ 37 you need the 128 row.
• Keeping the even rows in peasant multiplication. Strike rows where the halved number is even. The first row of 386 x 524 is even and must be struck.
• Rounding when halving. Drop the remainder: half of 193 is 96, not 97. The odd test has already accounted for the dropped 1.
• Picking rows in the wrong order in division. Work from the largest row down, and take a row only if it fits in what is left. Picking from the smallest row up gives the wrong rows.
• Repeating a unit fraction. 2/5 is not 1/5 + 1/5 in Egyptian notation. Use the table: 1/3 + 1/15.
• Treating the Rhind date as exact. Say "about 1550 BCE" or "about 1650 BCE" and name your source; the sources do not agree.
• Assuming the method is the fastest. It is the most general method that needs no tables. On special numbers, other methods take a fraction of the steps.

FAQ

What is Egyptian multiplication?

Egyptian multiplication is a method recorded in the Rhind Mathematical Papyrus. You double one factor repeatedly, mark the rows whose doubling counts (1, 2, 4, 8 and so on) add up to the other factor, and add the marked rows. For 41 x 59 the marked rows are 59, 472 and 1,888, which sum to 2,419.

How does Russian peasant multiplication work?

Write the two numbers side by side. Halve the left number (dropping remainders) and double the right number, row by row, until the left number is 1. Cross out rows where the left number is even and add the rest of the right column. For 47 x 53, halving 53 keeps 47, 188, 752 and 1,504, which sum to 2,491.

Why does Russian peasant multiplication work?

Halving and checking for odd numbers reads the multiplier's binary digits from the lowest up. The kept rows hold the multiplicand times the powers of two that make up the multiplier, and adding them is the distributive law.

How did the Egyptians divide?

By doubling the divisor and finding which rows add up to the dividend. For 7,429 ÷ 37, the rows for 128, 64 and 8 use up 7,400, so the quotient is 200 with 29 left over. The remainder was then written as parts of the divisor in unit fractions: 29/37 = 2/3 + 1/9 + 1/222 + 1/666.

What is an Egyptian fraction?

A sum of distinct unit fractions, such as 1/2 + 1/10 for 3/5. The Egyptians wrote all fractions this way, with 2/3 as the main exception. Any positive fraction can be written as an Egyptian fraction, for example by the greedy method that Fibonacci described in 1202.

How old is the Rhind Mathematical Papyrus?

MacTutor dates Ahmes's copy to about 1650 BCE; other references say about 1550 BCE, tying it to Year 33 of the Hyksos king Apepi. Ahmes says he copied a text about 200 years older. Rhind bought it in Luxor in 1858.

Is peasant multiplication faster than normal multiplication?

Not for someone fluent in the times tables: the school method writes fewer digits for every multiplication in this post. Peasant multiplication suits people who have not memorised the tables and multipliers with few 1 bits, and it is easier to check row by row.

Do computers still use shift and add?

Small processors without a multiply instruction do, in software. Hardware multipliers form the same partial products in parallel and add them in a tree, with refinements such as Booth recoding and Wallace trees.

Related posts in both series

The traditions series runs the same problem set through three other systems, and the comparison post puts them side by side:

• Indian and Vedic Mathematics Explained: the 16 Sutras, Śulba Sūtras, Zero, Āryabhaṭa, Brahmagupta and the Kerala School
• Chinese Mathematics Explained: Counting Rods, the Nine Chapters, Fangcheng, the Remainder Theorem and Horner before Horner
• Japanese Mathematics Explained: the Soroban, Anzan, Wasan, Seki Takakazu and Sangaku Temple Geometry
• Vedic vs Chinese vs Japanese Mathematics Compared: Same Problems, Three Systems

Doubling, checksums and checkable steps: an honest bridge

Safeguard does not do mathematics, and nothing in this post was computed by a Safeguard model; every number came from the Python script above. The parallel to our work is in the habits the method teaches. A doubling table is checkable row by row, casting out nines is a checksum like the hashes that confirm a downloaded package is the one that was published, and the same shift and add idea now sits inside every processor and every big-number library. If you build anything around this material, from a drill app for halving and doubling to a classroom notebook like the walkthrough, it runs on open source dependencies like any other software, and those dependencies need the same checking and timely fixes as the code in a production service.

More in this series

Other posts in our fast calculation methods series:

• Babylonian Mathematics Explained: Base 60, YBC 7289 and Plimpton 322
• Chisanbop Explained: Korean Finger Math to 99, With Worked Examples
• Fastest Mental Math Methods Compared: 14 Systems, Same 7 Problems
• Lattice Multiplication, Napier's Bones and the Slide Rule Explained
• Line Multiplication: The Stick Method, Japanese, Chinese or Neither?
• Maya Mathematics Explained: Base 20, Bar and Dot Numerals and Zero
• Mental Calculation Techniques of World Champions: Left to Right, Criss-Cross, Squares and Calendars
• Trachtenberg Speed System Explained: Rules for 11, 12 and Any Number

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

None of these demos involve any arithmetic; they show the software side described in the bridge above.

The first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal and asks it to fix a lodash CVE in a repository. It reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. The same flow applies to a web app for doubling and halving drills: scan the repository, then let the assistant propose the dependency upgrade under your approval.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. That suits teachers and students who keep scripts like the walkthrough above on their own laptops and want the scan to run where the code lives.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. If you already work with Claude while building an education app, it brings dependency findings into the same conversation, limited to the tools you allow.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• MacTutor History of Mathematics, Mathematics in Egyptian papyri
• MacTutor History of Mathematics, An overview of Egyptian mathematics
• MacTutor History of Mathematics, Egyptian numerals
• MacTutor History of Mathematics, Ahmes
• Wikipedia, Rhind Mathematical Papyrus
• Wikipedia, Rhind Mathematical Papyrus 2/n table
• Wikipedia, Moscow Mathematical Papyrus
• Wikipedia, Berlin Papyrus 6619
• Wikipedia, Ancient Egyptian multiplication
• Wikipedia, Egyptian fraction
• Wikipedia, Greedy algorithm for Egyptian fractions
• Wikipedia, Multiplication algorithm
• Wikipedia, Binary multiplier
• Wikipedia, Booth's multiplication algorithm
• Wikipedia, Wallace tree
• Wikipedia, Exponentiation by squaring
• Microchip, AVR Instruction Set Manual (DS40002198)
• CPython source, Objects/longobject.c
• Mental Calculation World Cup, recordholders.org

Further reading, cited in the text but not fetched for this post: A. B. Chace, L. S. Bull, H. P. Manning and R. C. Archibald, The Rhind Mathematical Papyrus (Mathematical Association of America, Oberlin, Ohio, 1927 to 1929); R. J. Gillings, Mathematics in the Time of the Pharaohs (MIT Press, 1972); Leonardo of Pisa, Liber Abaci (1202), translated by L. E. Sigler (Springer, 2002); J. J. Sylvester, "On a point in the theory of vulgar fractions", American Journal of Mathematics 3 (1880); A. D. Booth, "A signed binary multiplication technique", Quarterly Journal of Mechanics and Applied Mathematics 4(2), 1951; C. S. Wallace, "A suggestion for a fast multiplier", IEEE Transactions on Electronic Computers EC-13(1), 1964; A. Menezes, P. van Oorschot and S. Vanstone, Handbook of Applied Cryptography (CRC Press, 1996), Algorithm 14.79.

Last reviewed: 25 October 2026.