The rendering was for n=74 in fact, not for n=75. The pattern does seem to recur for even numbered n values and for those we think it matches GCD (where cells contain an even number of integers, and we render for the same even number of rows). But this has not been proved yet. However when n has odd values, the pattern does not always match GCD, it turns out. This is interesting and means that it may be a less “trivial” pattern in fact.

See the Mathematica notebook, which correctly renders it for any value.

Https://GitHub.com/shaunxcode/a-pattern-in-the-primes

See this animation by Ian Rust showing how the even values of n approach the GCD pattern as the values increase:

https://streamable.com/l7r96

However, for odd values of n, it does not match GCD. So it's not simply a drawing of the GCD pattern.

Well, for obvious reasons: when n is odd, and the row R is even (specifically, 2 mod 4, i.e. of the form 4k+2 for some k) and the column C is odd, then even if gcd(R, C) = 1, the set being considered contains only even numbers — note that it starts with R(R-1)N/2+C which will be even as R(R-1)/2 is odd and so is C - so you won't have any primes in it. (That is, you'll have a red cell, even where the gcd pattern has a black one.)

And when n is even, there's also a heuristic argument that there are only finitely many counterexamples; i.e. you should expect to find the pattern from your process exactly match that from just the gcd, beyond a few counterexamples: https://news.ycombinator.com/item?id=17106648

> the even values of n approach the GCD pattern as the values increase

Meaning that the chance of finding a prime in these sequences of N numbers approaches one, after eliminating the cases that make primes impossible (n odd and r=2 mod 4, gcd(r,c) > 1).

Is there any deeper meaning to that, or is it simply that the probability of finding a prime in any sequence of n numbers approaches one as n increases, excluding sequences in which primes are impossible?

This is fascinating!

Their picture is correct, but only because they are doing something more ridiculous than this. Every one of the squares in their picture represents 75 numbers, not 5 numbers.

UPDATE:

Thanks to comments from readers we have found that the pattern does not exactly match the GCD triangle for some values of the number of cells and rows.

This possibly makes it a more interesting finding. But it also means we can’t use GCD to render it quickly for all values.

In the code on Observable we were using GCD as a shortcut to render it because it saved time compared the earlier approach. However readers correctly pointed out that the rendering was not always correct using GCD.

Now that we know GCD doesn’t apply to all values of n, we are reverting to the original code, which generates the correct renderings for all values - but is slower - and there will be an update on Observable soon.

Meanwhile - to see the original code at work, and test it out for any value yourself, here is the Mathematica notebook code:

Https://GitHub.com/shaunxcode/a-pattern-in-the-primes

The Observable JavaScript code is being updated soon to account for this.

Join the discussion in the Telegram group as well - details below.

Click on the definition of T, and you see exactly the A054521 formula.

T = (n, k) => { return (GCD(n, k) == 1) ? 1 : 0; }

The given code doesn’t use primes, primesSet, or isPrime at all.

But that does produce a picture identical to theirs. Because they are using 75 numbers per square, they do end up hitting at least one prime in each box with (n,k)=1 for the first 75 rows. This pattern won't continue much longer, which is why they've conveniently stopped the picture at that point.

From what we have seen in our tests, the pattern holds for the number of rows n, where n = the number of integers contained in a cell. After n rows the symmetry breaks. We haven't tested every possible n yet however. It would be great to do more tests and let's see if there are exceptions.

Actually someone did point out an exception and it generates something very interesting we didn't see before. The pattern is different for odd n. But also has an interesting self-similarity. See the discussion on Telegram about this. https://t.me/joinchat/G8AnchIna2q8yn1lGHirkA

The claim is that using N numbers per square will result in the pattern holding for N rows, for arbitrarily large N.

Even if I’m misunderstanding how this is supposed to work for odd n, this claim fails for plenty of even n.

n = 14: fails on row 13, col 3

n = 20: fails on row 17, col 8

n = 30: fails on row 17, col 7

n = 38: fails on row 37, col 8

n = 44: fails on row 31, col 2

n = 50: fails on row 43, col 13

…

Ok going back to the mathematica version that does it the slower primality testing per terms in cell way I am seeing the deviations meaning the gcd triangle is not an exact match to what we have here.

Here is the code on GitHub - it renders it correctly and addresses the issues. Https://GitHub.com/shaunxcode/a-pattern-in-the-primes

From OP: > Interestingly, this same pattern holds for more numbers, and for different intervals.

He's not claiming it holds for _all_ n, just for _many_ n.

I think you may misunderstand what terms are in a cell. For instance in your first example what numbers live there? In that observable you can run cellToTerms(row,n,binomialCoEfficient2,col) to get the terms. You can then chain .map(isPrime) (for reasonable sizes it is slurping in data to make testing faster). Those fns are there for interactivity I have not gotten around to adding yet.

I used range(row * (row - 1) // 2 * n + col, row * (row + 1) // 2 * n + col, row) in Python. For n = 14, row = 13, col = 3, this is

[1095, 1108, 1121, 1134, 1147, 1160, 1173, 1186, 1199, 1212, 1225, 1238, 1251, 1264]

none of which are prime. cellToTerms(13, 14, binomialCoEfficient2, 3) in the observable gives the same list (though no such calls are made when generating the picture).

Those are some pretty basic checks to miss. Perhaps I've misread OP's claim.

I think OP is a bit confused, the post is very ambiguous and on telegram he added more info but still hasn't fully formalized what he's trying to say

OP here - really it’s just a matter of I found a cool thing and wanted others ideas/input. I never had a pretense of a proof or a formalization just a cool pattern that emerges from folding the Ulam Spiral up a certain way. I think we were over zealous in the gcd triangle being an exact correspondence now as it clearly is not for some cells.

The pattern does not exactly match GCD as it turns out - but that makes it more curious actually. Here is the Mathematica code that does work for other values.

Https://GitHub.com/shaunxcode/a-pattern-in-the-primes

Can you explain how that picture would be produced with 75 numbers per square? The generalization that seems obvious to me already fails in both cells of row 2, because 75 is odd:

row 1, col 1: [1, 2, 3, …, 75], has primes

row 2, col 1: [76, 78, 80, …, 224], no primes

row 2, col 2: [77, 79, 81, …, 225], has primes

You are completely right; their pattern holds iff (I believe, not proven!) the number they take 75 for is even. If you take any even number of rows (== amount of numbers per cell, in their construction), say 6, or 74, or 76, the pattern works.

No, it still fails for even n; see my other comment: https://news.ycombinator.com/item?id=17104624

Fair point, I missed that. Scratch my claim.

Then their claim that this pattern holds isn't even true; as pointed out elsewhere, and is obvious when you write out the sequence items explicitly in terms of their coordinates, any gcd!=1 cell will be red. But a gcd=1 cell need not be black, for many n.

Your point about the deviations is taken - the gcd triangle is not an exact fit for the pattern. Working on an updated version this evening. Specifically for odd n it does not work and there are occasional asymmetries.

UPDATE - Saturday May 19

The drawing has been updated on the blog post cited above; there was an error in the description of it, this has been clarified and the code has been updated as well

Join the Telegram group to discuss: https://t.me/joinchat/G8AnchIna2q8yn1lGHirkA

Note that Even and Odd Values of N have a very different pattern.

For example try using the values 99 and 99, and then 100 and 100, in this HTML PREVIEW VERSION:

https://htmlpreview.github.io/?https://github.com/acmegeek/p...

CODE TO TRY:

Javascript https://beta.observablehq.com/@montyxcantsin/unwinding-the-u...

Mathematica https://github.com/shaunxcode/a-pattern-in-the-primes

Perl https://www.dropbox.com/s/z5tfub5geyuctex/prime-draw.pl?dl=0

EXPLANATION:

In short, actually there are some curious patterns in this, and they are not simply equivalent to OEIS A054521 (as we, and others, initially thought they were).

For even values of n, they seem to approach the OEIS A054521 sequence as n increases. But for odd values the pattern is different and OEIS A054521 doesn't describe it at all. More discussion of this on the Telegram group...

Thanks for your comments; it helped me understand exactly what was being claimed, and what the observed pattern is.

For the benefit of others who may be similarly mystified, here's an elaboration. First, in vague terms, there are two things going on here:

1. If you colour a triangular grid according to the gcd of the coordinates, then you get a pretty picture (this is itself interesting IMO), and

2. If you colour a triangular grid according to a particular function involving prime numbers, then the picture will often (NOT ALWAYS!), and in many places (NOT EVERYWHERE!) resemble the pretty picture of (1) above.

Less vaguely, here are precise definitions:

--------------------

Draw a triangle (triangular grid) where row R (for R = 1, 2, 3, ...) has R cells or "columns" (C = 1, 2, 3, ..., R). Suppose we colour the cell at co-ordinates (R, C) to be

- black, if gcd(R, C) = 1 (that is, R and C have no common factors except of course 1), and

- red, if gcd(R, C) > 1 (that is, there is some number > 1 that divides both R and C).

(This is the sequence http://oeis.org/A054521.) Then, the triangle has a pretty and regular pattern, as shown in the post. This is not too hard to prove, but is IMO itself interesting, and a nice discovery for someone playing with numbers and visualizations. So congratulations to the authors for coming up with this.

Call this Drawing 1.

--------------------

Next, fix an even integer N, and for each pair of coordinates (R, C) with 1 ≤ C ≤ R, let S(R, C) be a particular set of N integers, to be defined precisely shortly. (Roughly, in row R, we take RN numbers and assign them to the C cells in a round-robin fashion.)

For example, for N = 10, the first 3 rows have 6 cells so 60 numbers, so in row 4, the numbers 61 to 100 are distributed as follows:

    S(4, 1) = {61, 65, 69, 73, 77, 81, 85, 89, 93, 97}

    S(4, 2) = {62, 66, 70, 74, 78, 82, 86, 90, 94, 98}

    S(4, 3) = {63, 67, 71, 75, 79, 83, 87, 91, 95, 99}

    S(4, 4) = {64, 68, 72, 76, 80, 84, 88, 92, 96, 100}

In general, to define the elements of the set S(R, C), start with (R(R-1)N/2 + C), and increase by R each time, until there are N integers. In Python notation,

    S[(R, C)] = range(R*(R-1)*N/2 + C, R*(R+1)*N/2 + C, R)

Then, colour the cell with coordinates (R, C) with:

- black, if any of the numbers in the set S(R, C) are prime, and - red, if none of the numbers in the set S(R, C) is prime.

Call this Drawing 2 (for a particular value of N).

--------------------

Now, note the following:

- when cell (R, C) in Drawing 1 is red, i.e. when gcd(R, C) > 1, then in Drawing 2, whatever the value of N, all the numbers in the set S(R, C) are divisible by that gcd, so none of them can be prime.

- when cell (R, C) in Drawing 1 is black, i.e. when gcd(R, C) = 1, then in Drawing 2, especially for larger values of N, you have a set of N integers that have no particularly forced reason to be composite, so it's rather likely that at least one of them may be a prime. (This can be made somewhat more precise using standard number-theory heuristics like the Cramer random model, but nothing that reaches the level of proof.)

So Drawing 2, which depends on the primes, is likely to resemble Drawing 1 (red in all the places where Drawing 1 has red), but with occasional additional red dots (where Drawing 1 has black) that break the nice, regular pattern. Some of these counterexamples are listed in this comment: https://news.ycombinator.com/item?id=17104624

(I haven't worked out the details but I think we can prove things like that there will be infinitely many of these counterexamples if we extend the triangle far enough, but also that the ratio (asymptotic density) of these counterexamples will be small. So "the pattern will kind of hold" is about all we can say.)

--------------------

What does all this tell us about primes? Unfortunately, not much it appears. To the extent that there is a nice pattern in the picture, it comes from the regular properties of the gcd function. And if one considers the deviations from the regular pattern as what's interesting, then it tells us things only in a diffuse way: whereas with Ulam's spiral one sees individual primes, here what one sees visually is cases where in a particular set of N numbers none of them happened to be prime.

Still, the pictures are pretty to look at, and that counts for something. :-)

Check the observable doc now https://beta.observablehq.com/@montyxcantsin/unwinding-the-u... should be more in line with original intention.

Thanks for an interactive version. Using this, you can check the examples that Anders pointed out in his comment here: https://news.ycombinator.com/item?id=17104624 -- for example, with n=20, see that row 17, column 8 does indeed have a red dot instead of black, which does not match the claimed pattern. (Edit: I wrote more in this comment: https://news.ycombinator.com/item?id=17106193)

Yes, the thing is the claimed pattern IS the one with the dot etc. the mistake we made was seeing how close the GCD triangle version fit and thinking it was the same when in fact it was not. The only claim I am making is that this is an interesting way to transform the ulam spiral into something less chaotic.

You mean 24/tau^2, right?