101–110 of 195 posts
Yep - we are not claiming to be mathematicians, we're pattern hunters... this is an open invitation to others with more expertise to chime in and help figure this out... it's possible it is a minor discovery or even not a discovery... or it could be useful or even very useful. We don't know. Please help us explore it!
This made me curious, so I wrote a javascript version that renders a larger image of it: http://www.gibney.de/parallax_primes
Earlier quoted context omitted.
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 …
This made me curious, so I wrote a javascript version that renders a larger image of it: http://www.gibney.de/parallax_primes
So does the pattern work or not? People are saying it's not plotting primes, but there is clearly a prime check in this code
Is there are particular reasoning or meaning to each dot being 6 numbers? Is there any significant changes if you pick other numbers per dot, following the same pattern? Based on the linked explanation here: https://beta.observablehq.com/@montyxcantsin/unwinding-the-u...
Because primes exist on a base 6 numeric scale. Where all prime numbers are multiples of 1 and 5.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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 …
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.
[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).
What would it look like if instead of a binary coloring, you used a gradient coloring representing the number of primes in each range?
replace the source with the one I dropped here and hit Go: https://pastebin.com/aw9nRmeZ
It's actually fun to run the original first and then watch the colors overlay on top of it.