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.