The number 20 lands in the same cell as 2; the reason is because of the sequence of primes preceding it. If one of the prior primes had not occurred, its absence would have altered the number line to loop around, and some other even number would have taken its place with 2. But the primes are as they are so 2 and 20 share the same cell and spin address – blue. Aside from being 2 mod 6, they have no other obvious commonality that would sort them from the 2 mod 6 numbers that have spin of red or yellow. I find this interesting and am exploring reasons this might be so. As a first step, I need a process to assign the spin to a given number.

The color spin addresses for numbers are generally straightforward – a composite number takes the spin of the prior prime. 4 spins blue because 3 spins blue. 8 is red because 7 is red. However, twin primes, and the 0 type numbers between them, are open to some interpretation. You may notice when I first laid out the hexagon in the video, 5 spins blue, and 6 spins red following 7. I like that from an artistic sense and because that is how they first appeared. But a more logical interpretation is 5 spins purple, like its later cellmate 23. I keep an eye on these points as I interpret data as I don’t want them to affect outcomes without remark. Fortunately, this issue only affects the a lesser twin prime and the number immediately after — and these, despite their abundance in the early numbers, grow rare as numbers get big.

**Figure 1.**

Sadly, my software (https://github.com/tsgallion/prime-hexagon) does not print out a pretty chart like this. Aside from 2 and 3, primes come in two flavors, 1 modulo 6 and 5 modulo 6, or the dark and light blue triangles in figure 2(a). The program determines where primes land in the hexagon by moving between the 6 possible positions where primes may land, figure 2(b) . The 1-type primes land in python cells 1, 3, and 5. The 5-type primes land in 0, 2, and 4 cells. Finally, it can print output in the form of figure 2(c).

**Figure 2**The first column is the prime number generated by primesieve (primesieve.org) prime generator imbedded in primespin.py. The second column is the position in the hexagon per my algorithm, numbering 0 through 5 representing the 6 positions in the hexagon a prime number may fall. The third column is the polarity at that position. For 1-type primes, the polarity is the stated value and is true of all number to the next prime. For 5-type primes, the polarity displayed is for the polarity up to, but not including that 5-type prime — so, its polarity, and the numbers that follow all the way to the next prime is the opposite of what is stated.

So, in short, blue = 1,1 or 2,-1; purple = 2,1 or 3,-1; red = 3,1 or 4,-1; yellow = 4,1 or 5,-1; green = 5,1 or 0,-1; cyan = 0,1 or 1,-1. I suspect lumping these slightly different values as the same, such as calling 1,1 and 2,-1 both blue, while true in 2D, might separate themselves in models of higher dimension. That type of assessment is beyond my current abilities and goals.

The final column is rotation, which I will set aside for now. However, it is the how the number line orbits the central point of the hexagon. Going from 0 to 17, the number line completes its first rotation of the hexagon… but that is soon undone and the hexagon rotates the other way for a time.