Maya mathematics is a base 20 place value system written from top to bottom with only three signs: a dot for one, a bar for five and a shell for zero. Its best known use is calendar arithmetic. The Long Count, the 260 day Tzolk'in, the 365 day Haab' and the Venus table of the Dresden Codex are all sums and remainders written in bars and dots.
This post works through it by hand. Every problem in our fixed problem set is written as vertical bar and dot numerals and worked step by step in base 20, and every number was checked with Python before it went into the text. Then we convert today's date into the Long Count, find the next Calendar Round anniversary, step through the Venus table the way a scribe would, and say plainly where Maya arithmetic is a historical fact and where it is a modern reconstruction.
Key takeaways
- Maya numerals need only three symbols. Five dots make a bar, four bars fill a place, and the next place up starts again with a dot. Any digit from 0 to 19 is at most four dots over three bars.
- Numbers are written vertically, largest place at the top: 1, 20, 400, 8,000 and so on.
- The Long Count calendar breaks the pattern once. Its third place is worth 360 days (18 x 20), not 400, so moving digits up a place does not always multiply by 20.
- The Maya zero, drawn as a shell, a flower or a head, was invented independently of the zeros of Mesopotamia and India. The Long Count needed it from the first century BCE.
- Base 20 numbers are shorter and 1/19 is simply 0.1111..., but the base 20 times table has 190 facts against 45 in decimal.
- There is no surviving evidence that the Maya multiplied or divided the way this post does. MacTutor's history says so directly. The worked multiplications, roots and divisions below show what the notation can do, not what a Maya scribe is known to have done.
The problem set for this series
This is the Maya post in a series on fast calculation methods. It follows our traditions series on Indian and Vedic mathematics, Chinese mathematics and Japanese mathematics, which work the same problems, and the three way comparison of those traditions. Base 20 digits are listed from the highest place down, separated by semicolons.
| Problem | Decimal answer | Pure base 20 | As a Long Count (days) |
|---|---|---|---|
| 98 x 97 | 9,506 | 1; 3; 15; 6 | 0.1.6.7.6 |
| 47 x 53 | 2,491 | 6; 4; 11 | 0.0.6.16.11 |
| 386 x 524 | 202,264 | 1; 5; 5; 13; 4 | 1.8.1.15.4 |
| 85² | 7,225 | 18; 1; 5 | 0.1.0.1.5 |
| √7,744 | 88 | 4; 8 | 0.0.0.4.8 |
| 7,429 ÷ 37 | 200 remainder 29 | 10; 0 remainder 1; 9 | 0.0.0.10.0 remainder 0.0.0.1.9 |
| 1/19 | 0.052631578947368421 repeating (18 digits) | 0.1111... repeating (1 digit) | not expressible: no fractions |
The two right hand columns differ once a number passes 359, because the Long Count's third place is worth 360 rather than 400.
The bar and dot diagrams in this post were not drawn by hand. A short Python script converted each number, drew the glyphs, and checked every carry, product and remainder against ordinary integer arithmetic.
A short timeline of Maya mathematics
Sources are listed at the end; where a date rests on one reading of a damaged inscription, the table says so.
| Date | Event |
|---|---|
| December 36 BCE | Earliest securely read Long Count date, 7.16.3.2.13, on Stela 2 at Chiapa de Corzo, Chiapas. Only the day name and the digits survive |
| 236 to 19 BCE | Takalik Abaj Stela 2, Guatemala. A badly battered Long Count that might be earlier; the k'atun digit could be 6, 11 or 16 |
| September 32 BCE | Tres Zapotes Stela C, Veracruz, Long Count 7.16.6.16.18, in Epi-Olmec rather than Maya style |
| 250 to 900 CE | The Classic Maya period, when Long Count dates are carved on hundreds of monuments |
| 320 CE | A carved plate dated 8.14.3.1.12, which MacTutor uses as its first example |
| 603 CE | A building completion date at Palenque, 9.8.9.13.0, with a zero in the last place |
| Early 9th century | Painted room at Xultun, Guatemala, with astronomical tables and simple calligraphic zeros, excavated in 2011 |
| 1021 to 1154 CE | Radiocarbon range for the Códice Maya de México (formerly the Grolier Codex), a partial Venus almanac |
| About 1200 to 1345 CE | Estimated date of the Dresden Codex, a copy of older tables; scholars differ on the exact span |
| July 1562 | Diego de Landa burns Maya books at Maní, Yucatán |
| 1880 | Ernst Förstemann publishes the first complete facsimile and decodes the bar, dot and zero numerals and the Long Count |
| 21 December 2012 | The Long Count reaches 13.0.0.0.0 again, the end of the 13th b'ak'tun |
How do Maya numerals work?
Three symbols: dot, bar and shell
A dot is one. A bar is five. A shell, or one of several other zero signs, means an empty place. Within one place you can stack at most four dots and three bars, so a place holds a value from 0 to 19. MacTutor suggests the dot may come from a pebble and the bar from a counting stick, and links five and twenty to fingers and toes, as a guess rather than a documented fact.
Here is every digit. Dots sit above bars, which is the most common arrangement in the codices. On some monuments the same digits are drawn turned on their side, with dots to the left of vertical bars.
0 1 2 3 4
◯ shell ● ● ● ● ● ● ● ● ● ●
5 6 7 8 9
━━━━━━━ ● ● ● ● ● ● ● ● ● ●
━━━━━━━ ━━━━━━━ ━━━━━━━ ━━━━━━━
10 11 12 13 14
━━━━━━━ ● ● ● ● ● ● ● ● ● ●
━━━━━━━ ━━━━━━━ ━━━━━━━ ━━━━━━━ ━━━━━━━
━━━━━━━ ━━━━━━━ ━━━━━━━ ━━━━━━━
15 16 17 18 19
━━━━━━━ ● ● ● ● ● ● ● ● ● ●
━━━━━━━ ━━━━━━━ ━━━━━━━ ━━━━━━━ ━━━━━━━
━━━━━━━ ━━━━━━━ ━━━━━━━ ━━━━━━━ ━━━━━━━
━━━━━━━ ━━━━━━━ ━━━━━━━ ━━━━━━━
Two things make this fast to read. First, you never count more than four of anything. Thirteen is "two bars and three dots", read at a glance. The Japanese soroban groups by five and one within a decimal place, while the Maya group by five and one within a twenty place. Second, adding two digits means pooling their symbols, with no addition table to memorise.
Writing numbers vertically in base 20
A number with more than one place is written as a column, with the largest place at the top. In pure base 20 the places, reading upward, are worth 1, 20, 400, 8,000 and 160,000. The number 13 needs one place:
place 13
1 ● ● ● (13)
━━━━━━━
━━━━━━━
The number 9,506, the answer to 98 x 97, needs four places: one 8,000, three 400s, fifteen 20s and six units.
place 9,506
8,000 ● (1)
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
400 ● ● ● (3)
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
20 ━━━━━━━ (15)
━━━━━━━
━━━━━━━
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
1 ● (6)
━━━━━━━
Check it: 1 x 8,000 + 3 x 400 + 15 x 20 + 6 = 8,000 + 1,200 + 300 + 6 = 9,506.
Converting a decimal number to base 20
The standard method is repeated division by 20, keeping the remainders. For 9,506:
| Step | Division | Quotient | Remainder (a digit, bottom place first) |
|---|---|---|---|
| 1 | 9,506 ÷ 20 | 475 | 6 |
| 2 | 475 ÷ 20 | 23 | 15 |
| 3 | 23 ÷ 20 | 1 | 3 |
| 4 | 1 ÷ 20 | 0 | 1 |
Read the remainders from the last to the first and you have 1; 3; 15; 6, which is the column above. Dividing by 20 is "halve and drop a zero", so this is quick mentally.
Reading a base 20 number back
Going the other way, start at the top and repeatedly multiply by 20 and add the next digit. For 1; 3; 15; 6 this is 1, then 1 x 20 + 3 = 23, then 23 x 20 + 15 = 475, then 475 x 20 + 6 = 9,506. Three multiplications by 20 and three additions. This nested evaluation is exactly the scheme the Chinese post calls Horner before Horner. It works for any base, and it is the fastest way to read a long Maya column into decimal.
The shell: one of the earliest independent zeros
What the zero signs look like
The zero people usually picture is the shell of the Dresden Codex, an oblong sign with pointed ends drawn in red on page 43b. It is only one of several. In a 2012 note, the epigrapher David Stuart lists three forms that are standard in Classic period stone texts: a three petalled sign that looks like a darkened flower, a "shell hand", and a head variant with a hand or a bony snake as its lower jaw. All three can be read as the syllable mi or the word sign MIH, the root of words meaning "nothing" in Mayan languages.
The Xultun room excavated in 2011 added a fourth, simpler form: a plain oval, which Stuart calls a calligraphic zero, probably used for quick working notes rather than formal inscriptions. He suggests the Dresden shells descend from this informal sign. The Kaqchikel Maya astronomer J. Mucía Batz, in a 2021 American Astronomical Society abstract, lists flower, seed, head and conch forms of the zero, Nik, and notes that in Kaqchikel "today" works as day zero.
How early was the Maya zero?
The honest answer has two parts.
First, the Long Count cannot work without a zero. A date like 9.8.9.13.0 needs something in the last place to show that place is empty, or the reader would take the four digits above it for 9.8.9.13 and get a different number of days. Classic Maya monuments from about 250 CE onward carry many such dates, and period endings such as 10.3.0.0.0 have three zeros in a row.
Second, the very earliest dates are harder to use as evidence than headlines suggest. The two oldest securely read Long Counts, 7.16.3.2.13 at Chiapa de Corzo (36 BCE) and 7.16.6.16.18 at Tres Zapotes (32 BCE), contain no zero digit as usually read. Mucía Batz nonetheless places the oldest Mesoamerican zero on Tres Zapotes Stela C. Both monuments are Epi-Olmec in style, not Maya, and the eight earliest Long Count dates all come from outside the Maya heartland, so the Long Count and its zero were probably used in the region before the Classic Maya adopted them.
What is not disputed is independence. The Maya zero developed with no contact with Mesopotamia, where scribes used a placeholder sign in late sexagesimal texts, or with India, where Brahmagupta in 628 CE gave rules for computing with zero as a number. Our Indian mathematics post covers the Indian story, including the dispute over the radiocarbon dates of the Bakhshali manuscript. One difference matters for arithmetic. Brahmagupta treated zero as a number you can add, subtract and multiply. The surviving Maya sources use zero as an empty place and as a sign of completion, as in "this count of k'atuns is full". There is no surviving Maya rule like "a number minus itself is zero". Given how many books were burned, that silence proves little either way.
The Long Count and its 18 x 20 irregularity
The units of the Long Count
The Long Count is a running count of days since a mythical creation date. It is written in five places, top to bottom, each with its own name.
| Place (top to bottom) | Name | Days in one unit | Rolls over at | Pure base 20 value of the same place |
|---|---|---|---|---|
| 5th | b'ak'tun | 144,000 | 20 (written as 13 at creation) | 160,000 |
| 4th | k'atun | 7,200 | 20 | 8,000 |
| 3rd | tun | 360 | 20 | 400 |
| 2nd | winal | 20 | 18 | 20 |
| 1st | k'in | 1 | 20 | 1 |
Higher units, each worth 20 of the one below, carry names invented by modern Mayanists, such as piktun.
The irregularity sits in one place only. Twenty k'in make a winal, but only 18 winals make a tun, so a tun is 360 days. Every place above the tun goes back to multiplying by 20, so a k'atun is 20 x 360 = 7,200 days and a b'ak'tun is 20 x 7,200 = 144,000 days. In the Long Count, the winal digit never goes above 17. The next day after 0.0.0.17.19 is 0.0.1.0.0, day 360.
Why 18?
The usual explanation, given both by MacTutor and by the summaries of the epigraphic literature, is that 360 days is close to a year, so the tun works as an approximate year and a k'atun as about 19.7 years. The Maya knew the real year was longer. MacTutor credits Maya astronomers with a year of 365.242 days against a modern 365.242198, and the 365 day Haab' calendar sits alongside the Long Count. The Long Count was a count of days, not a model of the solar year.
What the irregularity breaks
In a true place value system, moving every digit up one place multiplies the number by the base. The Long Count fails that test, and MacTutor gives the cleanest example.
- 9.8.9.13.0 = 9 x 144,000 + 8 x 7,200 + 9 x 360 + 13 x 20 + 0 = 1,357,100 days.
- 9.8.9.13, one place shorter = 9 x 7,200 + 8 x 360 + 9 x 20 + 13 = 67,873 days.
- 20 x 67,873 = 1,357,460, not 1,357,100. The 360 difference is 9 x (400 minus 360), the nine tuns that should have been worth 400 each.
So for calendar dates, "add a zero at the bottom" does not mean "times 20". For pure numbers it does. Here is the same quantity, 9,506, written both ways:
pure base 20 Long Count
◯ shell (0)
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
● (1) ● (1)
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
● ● ● (3) ● (6)
━━━━━━━
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
━━━━━━━ (15) ● ● (7)
━━━━━━━ ━━━━━━━
━━━━━━━
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
● (6) ● (6)
━━━━━━━ ━━━━━━━
Pure base 20 gives 1; 3; 15; 6. The Long Count gives 0.1.6.7.6: one k'atun (7,200), six tuns (2,160), seven winals (140) and six k'in. Both total 9,506. Every known large Maya number uses the 360 day tun. A pure base 20 system for everyday counting is a reasonable assumption, not a proven one; Georges Ifrah argued for it, as MacTutor reports, but no example survives.
So the arithmetic below uses pure base 20, where multiplication behaves cleanly, and the calendar sections use the Long Count, which is what the inscriptions record.
Adding and subtracting with bars and dots
The rules
Pool the symbols place by place, then tidy from the bottom up.
- Five dots in a place become one bar.
- In pure base 20, four bars in a place (twenty) become one dot in the place above.
- In the Long Count winal place, eighteen (three bars and three dots) becomes one dot in the tun place above.
- Subtraction is the reverse: if a place does not have enough, break one dot from the place above into twenty units, or into eighteen winals when you borrow from a tun.
Worked addition: 9,506 + 7,744 = 17,250
place 9,506 + 7,744 = 17,250
8,000 ● (1) ● ● (2)
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
400 ● ● ● (3) ● ● ● ● (19) ● ● ● (3)
━━━━━━━
━━━━━━━
━━━━━━━
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
20 ━━━━━━━ (15) ● ● (7) ● ● (2)
━━━━━━━ ━━━━━━━
━━━━━━━
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
1 ● (6) ● ● ● ● (4) ━━━━━━━ (10)
━━━━━━━ ━━━━━━━
Place by place, from the bottom:
| Place | Pool the symbols | Tidy up | Write | Carry up |
|---|---|---|---|---|
| Units | 6 (1 bar, 1 dot) + 4 (4 dots) = 1 bar, 5 dots | 5 dots become a bar: 2 bars | 10 | none |
| 20s | 15 (3 bars) + 7 (1 bar, 2 dots) = 4 bars, 2 dots | 4 bars become one dot above | 2 | 1 |
| 400s | 3 dots + 19 (3 bars, 4 dots) + 1 carried dot = 3 bars, 8 dots | 5 dots become a bar: 4 bars, 3 dots; 4 bars become one dot above | 3 | 1 |
| 8,000s | 1 dot + 1 carried dot = 2 dots | nothing to tidy | 2 | none |
The result reads 2; 3; 2; 10, and 2 x 8,000 + 3 x 400 + 2 x 20 + 10 = 17,250, which matches 9,506 + 7,744. Notice what you hold in memory at any moment: one place and at most one carried dot.
Worked subtraction: a Long Count distance number
Maya inscriptions often give a "distance number", the days between two events. Take the two dates MacTutor uses: the plate dated 8.14.3.1.12 (320 CE) and the Palenque building completed on 9.8.9.13.0 (603 CE). How many days apart are they?
place 9.8.9.13.0 - 8.14.3.1.12 = 0.14.6.11.8
b'ak'tun ● ● ● ● (9) ● ● ● (8) ◯ shell (0)
━━━━━━━ ━━━━━━━
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
k'atun ● ● ● (8) ● ● ● ● (14) ● ● ● ● (14)
━━━━━━━ ━━━━━━━ ━━━━━━━
━━━━━━━ ━━━━━━━
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
tun ● ● ● ● (9) ● ● ● (3) ● (6)
━━━━━━━ ━━━━━━━
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
winal ● ● ● (13) ● (1) ● (11)
━━━━━━━ ━━━━━━━
━━━━━━━ ━━━━━━━
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
k'in ◯ shell (0) ● ● (12) ● ● ● (8)
━━━━━━━ ━━━━━━━
━━━━━━━
| Place | Top minus bottom | Borrow? | Result |
|---|---|---|---|
| k'in | 0 minus 12 | Borrow one winal as 20 k'in: 20 minus 12 | 8 (winal 13 becomes 12) |
| winal | 12 minus 1 | no | 11 |
| tun | 9 minus 3 | no | 6 |
| k'atun | 8 minus 14 | Borrow one b'ak'tun as 20 k'atuns: 28 minus 14 | 14 (b'ak'tun 9 becomes 8) |
| b'ak'tun | 8 minus 8 | no | 0 |
The interval is 0.14.6.11.8, which is 14 x 7,200 + 6 x 360 + 11 x 20 + 8 = 103,188 days, about 282.5 years. The direct check is 1,357,100 minus 1,253,912 = 103,188.
Worked subtraction with the 18 borrow
The previous example never borrowed across the tun. This one does. How many days lie between that Palenque completion date and today, 25 October 2026, which is 13.0.14.0.16 in the Long Count (we derive that date below)?
place 13.0.14.0.16 - 9.8.9.13.0 = 3.12.4.5.16
b'ak'tun ● ● ● (13) ● ● ● ● (9) ● ● ● (3)
━━━━━━━ ━━━━━━━
━━━━━━━
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
k'atun ◯ shell (0) ● ● ● (8) ● ● (12)
━━━━━━━ ━━━━━━━
━━━━━━━
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
tun ● ● ● ● (14) ● ● ● ● (9) ● ● ● ● (4)
━━━━━━━ ━━━━━━━
━━━━━━━
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
winal ◯ shell (0) ● ● ● (13) ━━━━━━━ (5)
━━━━━━━
━━━━━━━
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
k'in ● (16) ◯ shell (0) ● (16)
━━━━━━━ ━━━━━━━
━━━━━━━ ━━━━━━━
━━━━━━━ ━━━━━━━
| Place | Top minus bottom | Borrow? | Result |
|---|---|---|---|
| k'in | 16 minus 0 | no | 16 |
| winal | 0 minus 13 | Borrow one tun as 18 winals: 18 minus 13 | 5 (tun 14 becomes 13) |
| tun | 13 minus 9 | no | 4 |
| k'atun | 0 minus 8 | Borrow one b'ak'tun as 20 k'atuns: 20 minus 8 | 12 (b'ak'tun 13 becomes 12) |
| b'ak'tun | 12 minus 9 | no | 3 |
The answer is 3.12.4.5.16, or 3 x 144,000 + 12 x 7,200 + 4 x 360 + 5 x 20 + 16 = 519,956 days. Python agrees: 1,877,056 minus 1,357,100 = 519,956. The one place where a careless reader goes wrong is the winal, where the borrow is worth 18, not 20. Borrow 20 there and the answer comes out two winals, or 40 days, too large.
Multiplying with bars and dots: a modern reconstruction
What the evidence says
MacTutor is blunt: the Maya "almost certainly did not have methods of multiplication" for their numbers and "definitely did not use division". What survives are tables of multiples, such as the Venus table's running totals of 584 days, built by repeated addition. MacTutor adds that the notation can support multiplication and division, citing Lambert, Ownbey-McLaughlin and McLaughlin's 1980 article "Maya arithmetic" in American Scientist, which showed how.
So the problem set below shows what the notation can do in modern hands, worked in pure base 20.
Digit products from three rules
The pleasant surprise is that you do not need a 19 x 19 times table to multiply two bar and dot digits. Every digit is some bars and some dots, and each pair of symbols multiplies by one of three rules:
| Pair | Value | Write it as |
|---|---|---|
| dot x dot | 1 x 1 = 1 | one dot |
| bar x dot | 5 x 1 = 5 | one bar |
| bar x bar | 5 x 5 = 25 | one dot in the 20s place plus one bar |
Example: 18 x 17. Eighteen is 3 bars and 3 dots; seventeen is 3 bars and 2 dots.
| Pairing | Count | Gives |
|---|---|---|
| bars x bars | 3 x 3 = 9 pairs | 9 twenties and 9 bars |
| bars of 18 x dots of 17 | 3 x 2 = 6 pairs | 6 bars |
| dots of 18 x bars of 17 | 3 x 3 = 9 pairs | 9 bars |
| dots x dots | 3 x 2 = 6 pairs | 6 dots |
| Total | 9 twenties, 24 bars, 6 dots |
Twenty four bars are 120, which is 6 twenties. So the total is 15 twenties and 6 units, or 15; 6, which is 306 = 18 x 17. It works, but count the effort: 30 symbol pairings for one digit product. This is transparent rather than fast. Memorising the products instead means 190 facts for the digits 1 to 19, against 45 in decimal.
The layout
For a whole number times a whole number, the layout used below is the same one the Chinese counting board uses, turned on its side:
- Write both numbers as base 20 columns.
- For each output place, add the digit products whose places sum to it. (Top digit times top digit lands highest.)
- Carry from the bottom place upward: each 20 in a place becomes one dot in the place above.
Working the problem set in base 20
98 x 97
In base 20, 98 is 4; 18 (four 20s and eighteen) and 97 is 4; 17.
place 98 97 98 x 97
8,000 ● (1)
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
400 ● ● ● (3)
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
20 ● ● ● ● (4) ● ● ● ● (4) ━━━━━━━ (15)
━━━━━━━
━━━━━━━
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
1 ● ● ● (18) ● ● (17) ● (6)
━━━━━━━ ━━━━━━━ ━━━━━━━
━━━━━━━ ━━━━━━━
━━━━━━━ ━━━━━━━
Step 1, the digit products by output place:
| Output place | Products | Sum |
|---|---|---|
| 400s | 4 x 4 | 16 |
| 20s | 4 x 17 + 18 x 4 = 68 + 72 | 140 |
| units | 18 x 17 | 306 |
Step 2, carry from the bottom up:
| Place | Raw value | Plus carry | Total | Write | Carry up |
|---|---|---|---|---|---|
| units | 306 | 0 | 306 | 6 | 15 |
| 20s | 140 | 15 | 155 | 15 | 7 |
| 400s | 16 | 7 | 23 | 3 | 1 |
| 8,000s | 0 | 1 | 1 | 1 | 0 |
The answer is 1; 3; 15; 6 = 9,506. Cost: four digit products, three carries, four places of output. The decimal schoolbook method also needs four digit products for a two digit by two digit sum, so base 20 gains nothing here. The Vedic near base trick is faster because 100 is a power of ten; in base 20, 100 is 5; 0, not a power of the base, so the trick does not transfer.
47 x 53
47 is 2; 7 and 53 is 2; 13.
place 47 53 47 x 53
400 ● (6)
━━━━━━━
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
20 ● ● (2) ● ● (2) ● ● ● ● (4)
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
1 ● ● (7) ● ● ● (13) ● (11)
━━━━━━━ ━━━━━━━ ━━━━━━━
━━━━━━━ ━━━━━━━
| Output place | Products | Sum |
|---|---|---|
| 400s | 2 x 2 | 4 |
| 20s | 2 x 13 + 7 x 2 = 26 + 14 | 40 |
| units | 7 x 13 | 91 |
| Place | Raw value | Plus carry | Total | Write | Carry up |
|---|---|---|---|---|---|
| units | 91 | 0 | 91 | 11 | 4 |
| 20s | 40 | 4 | 44 | 4 | 2 |
| 400s | 4 | 2 | 6 | 6 | 0 |
The answer is 6; 4; 11 = 6 x 400 + 4 x 20 + 11 = 2,491. In decimal the fastest route is the difference of squares, 50² minus 3² = 2,500 minus 9, because 47 and 53 sit either side of 50. In base 20, 50 is 2; 10, so the trick gains nothing.
386 x 524
This is where base 20 starts to pay. 386 is 19; 6 and 524 is 1; 6; 4. Two digits times three digits means six digit products, against nine in decimal.
place 386 524 386 x 524
160,000 ● (1)
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
8,000 ━━━━━━━ (5)
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
400 ● (1) ━━━━━━━ (5)
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
20 ● ● ● ● (19) ● (6) ● ● ● (13)
━━━━━━━ ━━━━━━━ ━━━━━━━
━━━━━━━ ━━━━━━━
━━━━━━━
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
1 ● (6) ● ● ● ● (4) ● ● ● ● (4)
━━━━━━━
| Output place | Products | Sum |
|---|---|---|
| 8,000s | 19 x 1 | 19 |
| 400s | 19 x 6 + 6 x 1 = 114 + 6 | 120 |
| 20s | 19 x 4 + 6 x 6 = 76 + 36 | 112 |
| units | 6 x 4 | 24 |
| Place | Raw value | Plus carry | Total | Write | Carry up |
|---|---|---|---|---|---|
| units | 24 | 0 | 24 | 4 | 1 |
| 20s | 112 | 1 | 113 | 13 | 5 |
| 400s | 120 | 5 | 125 | 5 | 6 |
| 8,000s | 19 | 6 | 25 | 5 | 1 |
| 160,000s | 0 | 1 | 1 | 1 | 0 |
The answer is 1; 5; 5; 13; 4. Read it back with the nesting method: 1, then 1 x 20 + 5 = 25, then 25 x 20 + 5 = 505, then 505 x 20 + 13 = 10,113, then 10,113 x 20 + 4 = 202,264. Correct.
Six digit products instead of nine, but harder ones: 19 x 6 = 114 is in no decimal times table. Base 20 trades more, easier steps for fewer, harder ones.
85²
85 is 4; 5. Squaring a two digit number a; b uses (20a + b)² = 400a² + 20 x 2ab + b².
place 85 85 squared
400 ● ● ● (18)
━━━━━━━
━━━━━━━
━━━━━━━
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
20 ● ● ● ● (4) ● (1)
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
1 ━━━━━━━ (5) ━━━━━━━ (5)
| Output place | Products | Sum |
|---|---|---|
| 400s | 4 x 4 | 16 |
| 20s | 2 x 4 x 5 | 40 |
| units | 5 x 5 | 25 |
| Place | Raw value | Plus carry | Total | Write | Carry up |
|---|---|---|---|---|---|
| units | 25 | 0 | 25 | 5 | 1 |
| 20s | 40 | 1 | 41 | 1 | 2 |
| 400s | 16 | 2 | 18 | 18 | 0 |
The answer is 18; 1; 5 = 18 x 400 + 20 + 5 = 7,225. The units product is a nice instance of the bar x bar rule: 5 is one bar, and bar x bar is one dot in the 20s place plus one bar, which is exactly the "write 5, carry 1" in the first row.
The decimal trick for squares ending in 5 (8 x 9 = 72, then append 25) relies on 5 being half of ten. The base 20 analogue needs a number ending in 10, such as 4; 10 = 90, whose square is 4 x 5 = 20 four hundreds plus 100, or 8,100. 85 ends in 5 in base 20, so no shortcut applies.
√7,744
The digit by digit square root works in any base. In base 20, 7,744 is 19; 7; 4. Group the digits in pairs from the bottom: the top group is 19, the next is 7; 4.
place 7,744 square root
400 ● ● ● ● (19)
━━━━━━━
━━━━━━━
━━━━━━━
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
20 ● ● (7) ● ● ● ● (4)
━━━━━━━
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
1 ● ● ● ● (4) ● ● ● (8)
━━━━━━━
| Step | What you do | Working | Result |
|---|---|---|---|
| 1 | Largest digit whose square fits in the top group 19 | 4² = 16 fits, 5² = 25 does not | First root digit 4 |
| 2 | Subtract and bring down the next pair | 19 minus 16 = 3; bring down 7; 4 to get 3; 7; 4 = 1,344 | Remainder 1,344 |
| 3 | Trial divisor: twice the root so far, shifted one place, plus the next digit d | (2 x 4 x 20 + d) x d = (160 + d) x d must fit in 1,344 | try d = 8 |
| 4 | Test d = 8 | 168 x 8 = 1,344, exactly | Second root digit 8, remainder 0 |
The root is 4; 8 = 4 x 20 + 8 = 88. Nothing is left over, so 7,744 is a perfect square. This is a modern method applied to Maya digits; nothing like it survives in a Maya source.
7,429 ÷ 37
Long division in base 20 is the same algorithm as in decimal, with 20 in place of 10. 7,429 is 18; 11; 9 and 37 is 1; 17.
place 7,429 divisor 37 quotient remainder
400 ● ● ● (18)
━━━━━━━
━━━━━━━
━━━━━━━
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
20 ● (11) ● (1) ━━━━━━━ (10) ● (1)
━━━━━━━ ━━━━━━━
━━━━━━━
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
1 ● ● ● ● (9) ● ● (17) ◯ shell (0) ● ● ● ● (9)
━━━━━━━ ━━━━━━━ ━━━━━━━
━━━━━━━
━━━━━━━
| Step | Working | Quotient digit | Remainder |
|---|---|---|---|
| 1 | Take the top two digits, 18; 11 = 371. How many 37s? 37 x 10 = 370 = 18; 10 | 10 (two bars) | 371 minus 370 = 1 |
| 2 | Bring down the units digit 9: 1; 9 = 29. How many 37s? None | 0 (a shell) | 29 = 1; 9 |
The quotient is 10; 0, which is 200, and the remainder is 1; 9 = 29. Check: 37 x 200 + 29 = 7,400 + 29 = 7,429.
This is the one problem where the zero does visible work. The quotient's bottom place is empty, and without a shell there the answer would read as 10 instead of 200. As in decimal, the hard part is guessing each quotient digit, and in base 20 trial quotients run up to 19.
1/19 as a base 20 fraction
The Maya, as far as any source shows, had no fractions. MacTutor says so plainly, and their lunar arithmetic worked around it by stating whole numbers of days against whole numbers of months, as we will see. So the Maya could not write 1/19 at all.
The notation, extended below the units place the way decimals extend below ones, handles it better than decimal does. Divide 1 by 19 in base 20: 20 ÷ 19 = 1 remainder 1, and the remainder 1 repeats forever. So 1/19 in base 20 is 0.1111..., one dot in every place below the point, repeating with period 1. That is because 19 is one less than the base, exactly as 1/9 = 0.1111... in decimal.
In decimal, 1/19 = 0.052631578947368421 repeating, with a period of 18 digits, because 10 has order 18 modulo 19. So on this one problem, base 20 turns the longest repeating decimal in the problem set into the shortest possible pattern. The Maya never had the fractional notation to use it.
Checking answers: casting out nineteens and twenty ones
Decimal casts out nines because 10 leaves remainder 1 modulo 9. Base 20 casts out nineteens for the same reason. Add the base 20 digits, reduce by 19, and the product of the checks must match the check of the product.
| Problem | Digit sum check of factors | Product of checks mod 19 | Digit sum of answer mod 19 | Agree? |
|---|---|---|---|---|
| 98 x 97 | 4 + 18 = 22, so 3; 4 + 17 = 21, so 2 | 6 | 1 + 3 + 15 + 6 = 25, so 6 | yes |
| 47 x 53 | 2 + 7 = 9; 2 + 13 = 15 | 135, so 2 | 6 + 4 + 11 = 21, so 2 | yes |
| 386 x 524 | 19 + 6 = 25, so 6; 1 + 6 + 4 = 11 | 66, so 9 | 1 + 5 + 5 + 13 + 4 = 28, so 9 | yes |
| 85² | 4 + 5 = 9 | 81, so 5 | 18 + 1 + 5 = 24, so 5 | yes |
Base 20 also gets a second cheap check that decimal does not have in the same form. Because 20 leaves remainder minus 1 modulo 21, an alternating digit sum checks answers modulo 21. For 98 x 97: 98 gives 18 minus 4 = 14, 97 gives 17 minus 4 = 13, 14 x 13 = 182, which is 14 modulo 21. The answer 1; 3; 15; 6 gives 6 minus 15 + 3 minus 1 = minus 7, which is also 14 modulo 21. Both checks pass. Neither check catches every error.
Calendar arithmetic: the Tzolk'in, the Haab' and the Calendar Round
The problem set tests the notation. The calendar is what the notation was for.
The Tzolk'in: 13 numbers and 20 day names
The Tzolk'in pairs a number from 1 to 13 with one of 20 day names. Both advance by one each day, so 1 Imix is followed by 2 Ik', then 3 Ak'bal, and after 13 Ben comes 1 Ix. Because 13 and 20 share no factor, every combination occurs exactly once before the cycle repeats, after 13 x 20 = 260 days. The day names, in order:
| Code | Name | Code | Name | Code | Name | Code | Name |
|---|---|---|---|---|---|---|---|
| 1 | Imix | 6 | Kimi | 11 | Chuwen | 16 | K'ib |
| 2 | Ik' | 7 | Manik' | 12 | Eb | 17 | Kaban |
| 3 | Ak'bal | 8 | Lamat | 13 | Ben | 18 | Etz'nab |
| 4 | K'an | 9 | Muluk | 14 | Ix | 19 | Kawak |
| 5 | Chikchan | 10 | Ok | 15 | Men | 0 | Ajaw |
The codes follow the convention Mucía Batz describes for the K'iche' count, with Ajaw as 0. That choice turns Tzolk'in arithmetic into remainders: the day name code is simply the day count modulo 20, plus a fixed offset. Nobody knows why the Tzolk'in has 260 days. MacTutor reports two unproven suggestions: the gap between the sun's overhead passages in the tropics, and 13 gods times the 20 digits of a person.
The Haab': 18 months of 20 days, plus 5
The Haab' is a 365 day year: 18 named months of 20 days (Pop, Wo, Sip, Sotz', Sek, Xul, Yaxk'in, Mol, Ch'en, Yax, Sak, Keh, Mak, K'ank'in, Muwan, Pax, K'ayab, Kumk'u) and then Wayeb', five days thought unlucky. Days in each month run from the "seating" of the month, usually counted as day 0, up to 19. So the Haab' position of a date is a number from 0 to 364: the month index times 20 plus the day. For example 8 Kumk'u, the eighteenth month (index 17), is position 17 x 20 + 8 = 348.
The Haab' had no leap day, so it slipped against the seasons by about a quarter of a day a year.
The Calendar Round: 18,980 days
A Calendar Round date names both the Tzolk'in and the Haab' position, for example 4 Ajaw 8 Kumk'u. It repeats when both cycles line up again, after the least common multiple of 260 and 365:
- 260 = 2² x 5 x 13 and 365 = 5 x 73.
- They share one factor, 5, so the least common multiple is 260 x 365 ÷ 5 = 18,980 days.
- That is 73 Tzolk'in cycles and 52 Haab' years, the 52 year cycle familiar across Mesoamerica.
The shared factor of 5 has a consequence people often miss. There are 260 x 365 = 94,900 ways to pair a Tzolk'in day with a Haab' position, but only 18,980 of them ever happen, one in five. A Calendar Round like "4 Ajaw 9 Kumk'u" can never occur. This is the same structure as the Chinese remainder theorem in the Chinese mathematics post: a date is fixed by its remainders modulo 260 and 365, and because the moduli are not coprime, the remainders must agree modulo 5 for a solution to exist. It is also why only four day names, the "year bearers", can fall on 0 Pop.
Worked: today's date in the Long Count
To convert a Western date you need a correlation constant, the Julian Day Number of the creation date. The consensus value is 584,283, the Goodman, Martínez and Thompson (GMT) correlation; an alternative two days later, 584,285, is sometimes used. With 584,283, day zero of the Long Count, written 13.0.0.0.0 4 Ajaw 8 Kumk'u, is 11 August 3114 BCE in the proleptic Gregorian calendar.
Step 1. The Julian Day Number of 25 October 2026 is 2,461,339.
Step 2. Subtract the correlation constant: 2,461,339 minus 584,283 = 1,877,056 days since creation.
Step 3. Divide down through the Long Count units:
| Unit | Division | Digit | Remainder |
|---|---|---|---|
| b'ak'tun (144,000) | 1,877,056 ÷ 144,000 | 13 | 5,056 |
| k'atun (7,200) | 5,056 ÷ 7,200 | 0 | 5,056 |
| tun (360) | 5,056 ÷ 360 | 14 | 16 |
| winal (20) | 16 ÷ 20 | 0 | 16 |
| k'in (1) | 16 | 16 | 0 |
So today is 13.0.14.0.16. In bars and dots:
place 25 Oct 2026
b'ak'tun ● ● ● (13)
━━━━━━━
━━━━━━━
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
k'atun ◯ shell (0)
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
tun ● ● ● ● (14)
━━━━━━━
━━━━━━━
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
winal ◯ shell (0)
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
k'in ● (16)
━━━━━━━
━━━━━━━
━━━━━━━
Step 4. The Tzolk'in. Creation was 4 Ajaw. The number advances by the day count modulo 13 and the name by the day count modulo 20. 1,877,056 leaves remainder 12 when divided by 13, so the number is 4 + 12 = 16, which wraps to 3. It leaves remainder 16 when divided by 20, so the name code is 0 + 16 = 16, K'ib. Today is 3 K'ib.
Step 5. The Haab'. Creation was 8 Kumk'u, position 348. 1,877,056 leaves remainder 226 when divided by 365, and 348 + 226 = 574, which wraps to 574 minus 365 = 209. Position 209 is 10 x 20 + 9, the eleventh month (index 10) day 9: 9 Sak.
Full date: 13.0.14.0.16 3 K'ib 9 Sak. That matches the date shown on Wikipedia's Maya calendar page for 25 October 2026, which uses the same GMT constant.
Notice the oddity of the b'ak'tun. At creation the count was written 13.0.0.0.0, not 0.0.0.0.0, as if a previous era of 13 b'ak'tuns had just completed. On 21 December 2012, 1,872,000 days later, it read 13.0.0.0.0 again, on 4 Ajaw 3 K'ank'in. Susan Milbrath of the Florida Museum of Natural History said at the time that there is no record the Maya expected the world to end then, and a Palenque inscription projects a date into 4772 CE, just after the first piktun, 1.0.0.0.0.0, completes on 13 October 4772.
Worked: the next 1 Ajaw
1 Ajaw matters because the Dresden Venus table is built around it. How many days from today, 3 K'ib, until the next 1 Ajaw?
- The name must move from K'ib (16) to Ajaw (0, or 20): 4 days, plus any multiple of 20.
- The number must move from 3 to 1: 11 days (3 + 11 = 14, which wraps to 1), plus any multiple of 13.
- Find the smallest d that is 4 modulo 20 and 11 modulo 13. Try 4, 24, 44 and so on: 4 leaves 4 modulo 13, 24 leaves 11. So d = 24.
The next 1 Ajaw is 24 days from today, on 18 November 2026 (Long Count 13.0.14.2.0, Haab' 13 Keh).
Worked: the next Calendar Round anniversary of creation
When does 4 Ajaw 8 Kumk'u next come round? It recurs every 18,980 days from creation. 1,877,056 ÷ 18,980 is 98.9, so the next recurrence is the 99th: 99 x 18,980 = 1,879,020 days, which is 13.0.19.9.0. That falls 1,964 days from today, on 11 March 2032.
The Dresden Codex Venus table
What the table is
The Dresden Codex is one of four Maya books to survive the Spanish conquest. It is a screenfold of 78 pages of bark paper, held today by the Saxon State and University Library (SLUB) in Dresden. Pages 24 and 46 to 50 hold the Venus table. In Harvey and Victoria Bricker's description, quoted on Wikipedia's Maya astronomy page, the table lists the Tzolk'in days of Venus's four appearances and disappearances in each of 65 consecutive cycles, about 104 years, with the emphasis on its first appearance as morning star, which was treated as a time of danger. They note it was reused with at least four starting dates.
The Maya divided one Venus cycle of 584 days into four canonical stretches: 236 days as morning star, 90 days invisible behind the sun, 250 days as evening star and 8 days invisible in front of it. 236 + 90 + 250 + 8 = 584. The real average synodic period is 583.92 days, and individual cycles vary between about 576.6 and 588.1 days.
The arithmetic that makes it work
Three numbers carry the whole table, here as Long Count spans:
place 584 2,920 37,960
b'ak'tun ◯ shell (0) ◯ shell (0) ◯ shell (0)
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
k'atun ◯ shell (0) ◯ shell (0) ━━━━━━━ (5)
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
tun ● (1) ● ● ● (8) ━━━━━━━ (5)
━━━━━━━
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
winal ● (11) ● ● (2) ● ● ● (8)
━━━━━━━ ━━━━━━━
━━━━━━━
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
k'in ● ● ● ● (4) ◯ shell (0) ◯ shell (0)
- 584 days is one Venus cycle, 1.11.4 in the Long Count.
- 5 x 584 = 2,920 = 8 x 365. Five Venus cycles equal eight Haab' years exactly, so after 2,920 days Venus returns to the same Haab' position. That is 8.2.0 in the Long Count.
- 65 x 584 = 37,960 = 146 x 260 = 104 x 365 = 2 x 18,980. After 65 Venus cycles, the Venus count, the Tzolk'in, the Haab' and the Calendar Round all line up at once. That is 5.5.8.0 in the Long Count, and it is the 104 year period MacTutor describes as a moment of great celebration.
Stepping the Tzolk'in through one row shows how a scribe could build the table by repeated addition alone. 584 leaves remainder 12 modulo 13, so each Venus cycle moves the day number down by one; it leaves remainder 4 modulo 20, so the day name moves forward four places.
| Venus cycle | Days from start | Tzolk'in date |
|---|---|---|
| 0 | 0 | 1 Ajaw |
| 1 | 584 | 13 K'an |
| 2 | 1,168 | 12 Lamat |
| 3 | 1,752 | 11 Eb |
| 4 | 2,336 | 10 K'ib |
| 5 | 2,920 | 9 Ajaw |
After five cycles the name is Ajaw again but the number has dropped from 1 to 9, because 2,920 leaves remainder 8 modulo 13. It takes 13 rows of five cycles, 65 cycles in all, for the number to come back to 1: 37,960 leaves remainder 0 modulo both 13 and 20.
The Códice Maya de México, radiocarbon dated by an INAH team in 2018 to between 1021 and 1154 CE, holds the same Venus dates for half of the Dresden cycles. Its "ring numbers" give intervals in bars and dots: page 7 shows a bar and three dots, so the reader counts 8 days from, say, 10 Lamat to 5 K'ib (10 + 8 = 18, which wraps to 5).
The drift problem
The canonical 584 is 0.08 days longer than the true mean of 583.92. Over 65 cycles that error grows to 65 x 0.08 = 5.2 days, enough to put the predicted first morning appearance visibly wrong. The Dresden table appears to include a correction scheme so it could be reused. Aveni and the Brickers discuss how it may have worked; the schemes are reconstructions, so we do not pick one. The method is the point: whole day counts, no fractions, and corrections in whole days.
The eclipse table and the lunar month
Pages 51 to 58 of the Dresden Codex hold an eclipse table spanning 405 lunations, about 33 years. The arithmetic coincidence is neat: 405 mean lunations are 405 x 29.53059 = 11,959.9 days, and 46 Tzolk'in cycles are 46 x 260 = 11,960 days. So the eclipse table, like the Venus table, closes on a whole number of 260 day cycles.
The Maya expressed the length of the month without fractions, as a ratio of whole numbers. MacTutor reports two inscriptions:
| Site | Recorded relation | Implied month length | Error against 29.53059 days |
|---|---|---|---|
| Copán | 149 lunations = 4,400 days | 29.5302 days | about 34 seconds short |
| Palenque | 81 lunations = 2,392 days | 29.5309 days | about 24 seconds long |
(MacTutor gives the Palenque value as 29.5308; dividing 2,392 by 81 gives 29.530864, which rounds to 29.5309.) Stating a rate as whole days per whole months is precise astronomy without fractions.
Is base 20 fast? Counting the steps
No measured speed records exist for Maya arithmetic, so the only fair comparison is to count work, with decimal schoolbook arithmetic as the reference.
| Measure | Decimal schoolbook | Pure base 20, bars and dots | Comment |
|---|---|---|---|
| Digits in 202,264 | 6 | 5 | Base 20 numbers are about 23 percent shorter (log 10 ÷ log 20 = 0.77) |
| Digit products for 386 x 524 | 9 | 6 | Fewer, but harder products such as 19 x 6 |
| Distinct times table facts (digits 1 to the base minus 1, a x b counted once) | 45 | 190 | Or three symbol rules and a lot of counting |
| Adding two digits | Memorised table | Pool symbols, five dots make a bar | Base 20 needs no addition table at all |
| Largest single digit product | 9 x 9 = 81 | 19 x 19 = 361 | Bigger products and carries, bigger mental load |
| Repeating pattern of 1/19 | 18 digits | 1 digit | Base 20 wins clearly |
| Cheap error checks | Casting out 9s; alternating 11s | Casting out 19s; alternating 21s | Equivalent strength |
| Calendar intervals | Convert to days and back | Native: subtract column by column | Long Count wins for its own job |
Bar and dot addition is genuinely easy, with nothing to memorise. Multiplication is either slow or memory heavy. The notation excels at what it was built for: adding and subtracting day counts and stepping through cycles.
A practice plan
- Day 1. Learn the 20 digits until you read each without counting, then convert ten numbers below 8,000 into base 20.
- Day 2. Add three place base 20 numbers with pebbles and sticks, choosing big digits to force carries.
- Day 3. Subtract Long Count dates, including three that borrow across the winal, and check each in days.
- Day 4. Convert your birthday and today into the Long Count and Calendar Round with 584,283.
- Day 5. Build five rows of the Venus table from 1 Ajaw, then check the week's answers by casting out nineteens.
Common mistakes
- Borrowing 20 at the winal. In the Long Count one tun is 18 winals. Borrow 20 and you are 40 days out.
- Using pure base 20 values for Long Count dates. 9.8.9.13.0 is 1,357,100 days, not 1,357,460. Use 360 for the tun place.
- Reading the column the wrong way up. The largest place is at the top. A two place number 4; 18 is 98, not 18 x 20 + 4 = 364.
- Dropping the shell. A missing zero shifts every digit above it down a place. In 7,429 ÷ 37, losing the shell turns 200 into 10.
- Saying the Maya multiplied like this. The worked products here are modern. MacTutor says the Maya almost certainly did not multiply this way.
FAQ
How do Maya numerals work?
A dot is 1, a bar is 5 and a shell is zero; up to four dots and three bars give 0 to 19 in one place. Places stack vertically, largest at the top, each worth 20 times the one below, except the Long Count's third place, worth 18 times the one below.
Why did the Maya use base 20?
The usual explanation is counting on fingers and toes, and the role of five in the bars supports it. No Maya source states a reason, so treat this as a strong guess rather than a fact.
Did the Maya invent zero?
They invented a zero independently. The Long Count, in use in the region from the first century BCE, requires a placeholder for empty places, and Classic Maya inscriptions use zero signs routinely. India's zero, a number in Brahmagupta's rules of 628 CE, developed separately and is the ancestor of ours.
What is the Long Count?
A count of days from a creation date that the GMT correlation puts at 11 August 3114 BCE (proleptic Gregorian). It is written in five places: b'ak'tun (144,000 days), k'atun (7,200), tun (360), winal (20) and k'in (1). Today, 25 October 2026, is 13.0.14.0.16.
How do you convert a date to the Maya calendar?
Find the Julian Day Number of the date, subtract 584,283, and divide the result successively by 144,000, 7,200, 360 and 20. For the Tzolk'in, add the day count to 4 Ajaw modulo 13 and 20; for the Haab', add it to position 348 (8 Kumk'u) modulo 365.
Could the Maya multiply and divide?
Not on any surviving evidence. They built tables of multiples by repeated addition. Their notation supports multiplication and division, as modern authors have shown, but no Maya source does either.
What is the Dresden Codex Venus table?
A table on pages 24 and 46 to 50 of the Dresden Codex listing the Tzolk'in dates of Venus's appearances and disappearances over 65 cycles of 584 days, 37,960 days in all, which is exactly two Calendar Rounds.
Is Maya arithmetic faster than decimal?
For addition and calendar intervals it is simple and needs no memorised table. For multiplication it needs either slow symbol pairing or a much larger times table. No timed comparisons exist, so any claim that it is faster overall is unsupported.
Where Safeguard fits
Safeguard does not do mathematics, and nothing in this post was computed by a Safeguard model; the conversions, carries and calendar dates were checked with plain Python. The honest parallel is about checkable steps. A Maya scribe could only reuse a Venus table because every entry was a whole number that anyone could re-add and compare, and errors were corrected at known points rather than hidden. A software supply chain needs the same property: every dependency you build with should be identifiable, compared against a known good version and corrected openly when it drifts, and a script as small as the one behind this post's diagrams still runs on an interpreter and pulls in packages that can carry known vulnerabilities. The section below explains how Safeguard closes that gap when a fix exists and when it does not.
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
- Egyptian and Russian Peasant Multiplication: Doubling and Binary
- 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?
- 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.
| Your situation | What to use |
|---|---|
| A fixed version exists | Autonomous remediation opens the upgrade pull request; Gold Open Source confirms the safe version |
| You need to know today whether you are affected | Gold Open Source lookup and "Am I affected?" checker, free and without login |
| You want vulnerable versions to stop shipping | The Gold scan GitHub Action in CI, plus Safeguard policies and gates |
| Upstream has no fix yet, or will not ship one | A custom Gold request; fork and patch (early access) |
| You want to start clean on new projects | Pull hardened components and images from Gold Registry |
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
These demos show dependency workflows, not mathematics. You can download Safeguard and follow the CLI docs to try them on your own projects.
This demo is a real CLI session. After installing, safeguard opens the interactive terminal; asked to "fix the lodash CVE in this repo", 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 the JavaScript or Python behind a calendar converter, a teaching site or a numerals drawing script like the one used for this post.
Click through it at your own pace, or open it full screen.
This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Pointed at a project folder, the scan lists the packages and versions the project depends on and their known vulnerabilities, so you know what to update before you share or deploy it.
Click through it at your own pace, or open it full screen.
Quick check
Subtract the Long Count dates 9.12.0.5.4 minus 9.11.3.10.9. What is the interval?
0.0.16.12.15, or 6,015 days. The k'in borrows a winal as 20 (24 minus 9 = 15). The winal must borrow a tun, but the tun is 0, so the tun first borrows a k'atun as 20 tuns, then lends one tun as 18 winals (22 minus 10 = 12), leaving 19 tuns; 19 minus 3 = 16. The k'atun gives 11 minus 11 = 0. Check: 1,382,504 minus 1,376,489 = 6,015.
Why does 1/19 repeat with period 1 in base 20 but period 18 in decimal?
Because 19 is one less than 20. Dividing 1 by 19 in base 20 gives 20 ÷ 19 = 1 remainder 1 at every step, so every digit is 1 (one dot). In decimal, the remainders cycle through all 18 nonzero values before repeating, because 10 has order 18 modulo 19.
Sources
- MacTutor History of Mathematics: Mayan mathematics (J. J. O'Connor and E. F. Robertson)
- MacTutor History of Mathematics: A history of zero
- W. A. Saturno, D. Stuart, A. F. Aveni and F. Rossi, Ancient Maya astronomical tables from Xultun, Guatemala, Science 336 (2012), 714 to 717 (PubMed abstract)
- David Stuart, The Calligraphic Zero, Maya Decipherment (15 June 2012)
- J. Mucía Batz, "Nik": The Zero in Vigesimal Maya Mathematics, Bulletin of the AAS 53(1), 2021
- Wikipedia: Maya numerals
- Wikipedia: Mesoamerican Long Count calendar
- Wikipedia: Maya calendar (Calendar Round, year bearers and the current date)
- Wikipedia: Tzolk'in
- Wikipedia: Haab'
- Wikipedia: Dresden Codex
- Wikipedia: Maya astronomy (Venus table, eclipse table, quoting Bricker and Bricker)
- Wikipedia: Maya Codex of Mexico (2018 INAH dating, ring numbers)
- Wikipedia: Chiapa de Corzo (Stela 2)
- FAMSI: The Dresden Codex
- Harvey M. Bricker and Victoria R. Bricker, Astronomy in the Maya Codices (American Philosophical Society, 2011), cited through Wikipedia
- J. B. Lambert, B. Ownbey-McLaughlin and C. D. McLaughlin, "Maya arithmetic", American Scientist 68(3) (1980), 249 to 255, cited through MacTutor
- Anna Blume, "Maya Concepts of Zero", Proceedings of the American Philosophical Society 155(1) (2011), 51 to 88, cited through Stuart
Last reviewed: 25 October 2026. Dates for early inscriptions and for the Dresden Codex are disputed in the literature; the Long Count conversions here use the GMT correlation constant 584,283.
