You're right, that is damn close. I was following his last example in A-New-Approach.. and he almost hits a few of our variables (d+1 instead of d, thus missing our e-value).
I've been suspecting for a while that VQC has actually been dropping hints for all three keys, mixed in with each other. I believe the smooth numbers is part of one key, the x+n triangle is part of another and that some of his other hints belong to the third part.
I've been busy with life for a while, but I did have some realizations the past few weeks.
I can't believe I missed the sqrt(2d), it's obvious now, but it's how you find the triangular base of d. Take a triangle n(n-1)/2 = k. To find the triangular base you do 2k = n(n-1), then the square root will be sqrt(2k) = sqrt(n(n-1)). Floor this number and you will have (n-1).
Yeah here I suspect aan(n-1) belongs to either the smooth numbers key or the third key.
So it's been a while since I posted much, I've been busy looking over patterns in the grid, but with >>7915 something hit me. What if we've been doing this wrong. We're trying to triangulate (x+n)^2, but we only have f and 2d remainders right? What if we could increase it? What if we could add more information to our data?
I've attached an image that shows my idea. If we connect (d + n)^2 with (x + n)^2 at nn, we have a new square that contains more information that we have. The equation for this square is:
(d + n + x)^2 = nn + dd + 2d(n - 1) + 2d(n - 1) + f + 2 + f - 2 + 2dx
This can be simplified to:
nn + dd + 2d(2n + x - 2) + 2f + 1
In this "upper" square the dd will cover the entire outside of the triangle, meaning the triangle base will be smaller than the u of dd. Essentially, we have a new square and an upper limit of the triangle base of (x+n).
Another thing is that our dd square will now occupy one part of the new square, while xx will occupy the opposite side.
I've also been a bit huffing about the fractal VQC has been talking about, but now I think I'm starting to see it. If we combine the squares as in the attached image we can now see what could potentially be a fractal. I'm not entirely sure how one would map it / graph it, but it's a start.
I do feel like something clicked, but I'll be honest and say that we've all had that feeling before.
A legend for the image:
In the upper left corner you see the dd square with the f/2d extension on the side (n=6) along with the nn square shared between (d+n)^2 and (x+n)^2.
In the lower right corner you see xx and the extended f/2x around it.
As for what we're trying to do, which is find (x+n)^2, this will exist inside of this (d+n+x)^2 with nn in the center, think of it like our original (x+n)^2 = nn + 2d(n-1) + f - 2 equation, except this is inside of dd + 2d(n-1) + 2dx + f + 2.
Attached is an image showing the coloring of the (d+n+x)^2 square.
The outer layer is dd, f + 2, 2d(n-1), 2dx, 2d(n-1), f - 2 and nn in the middle.
I was playing around with the Euler Totient. Based on the triangle from >>8083 I wanted to see how it looked like as a square. Not sure if this is the fractal we're looking for, but never the less it looks quite pleasing. You can see how there are squares and triangles pretty much everywhere inside of it. I really don't think this is where we are moving with regards to our fractal, but it was fun reading about the function and playing a bit with it.
Yes, it was late and my brain was mushy.
I got something I can't quite figure out. I suspect it's a fluke, but at the same time, it's a very convenient fluke. It's not limited to one cell, but multiple (e, n)'s. Not entirely sure how many.
I was playing with >>8260 and thinking about how our squares can be expressed as either 8 triangles + 1 or sum of two sets of 4 triangles depending on parity.
So assume k is even, then k + 1 is odd. That means we have 8T(u) + 1 - 4(Tu - T(u-1)). I was playing around with it, looking at what the numbers were for different cells and stuff, but then for some reason, (divine intervention?) I decided to just see what 8Tu - 4T(u + 1) was. Note here u is from d, so it's based only on the d within those rows.
I noticed in (3, 6) that 8T(u) - 4T(u + 1) (Again u is from d) was the smooth numbers for those cells. As in, if this pattern had held for ALL rows it would have been solved. It doesn't though, but it does for several others. Like (1, 5) and (11, 10).
Take any given cell from (1, 5) or (3, 6) or (11, 10) and probably a lot more and then calculate the u for d. Then calculate 8T(u) - 4T(u + 1). This will give you the smooth number for that cell. Then just take BigN - 8T(u) - 4T(u + 1) = n.
For other cells there appears to be an offset, as in the numbers are slightly off. I'm not sure why yet or even if this offset can be "known" based on certain other elements, but nevertheless it's the closest I've been to "touch" a solution.>>8260
Some offsets are limited to single integers for all the records in that row, while others move depending on different elements. Like I said, I haven't quite figured it out yet.
So e is the natural base for numbers that exist within it's column?
To follow up a bit on this one, I found a russian paper regarding pythagoras triples and fermats factorization. The paper outlines a method of iterating / finding all the pythagorian triples, which has a very nice correspondence to our grid.
Take the d from (0, e^2) and take the a from (e^2, 1) (Note the t-index in column e^2 has to be (e + 1)/2 to align the row with correct (0, e^2, t)) and then compute absolute(d^2 - a^2). It will give you a square.
I found this as I was looking to see if there was a pattern with regards to the differences as mentioned in the previous post (It appears to be a a part of the triplet, as in x, y or z from x^2 - y^2 = z^2).
It also appears that our smooth numbers exist in (0, e^2) as d-values, but I'm not entirely sure how to "get" the correct one yet. Given that with a large enough number the t-value for that smooth number would be too far down the list to find it iteratively. Although, we know that the smooth number has to be less than our N number, so it should cut down on the search space.
He didn't specify all that much though. Are we sure he is referencing to the 'a' value in (e+1)?
In (e+1, 1) the d-values are the same as the a-values in (e, 1) in which case, if he was talking about (e+1, 1).d then it would be the same rule we've talked about before.
I had that issue a while ago too, and it was just how I computed the nth row that was wrong. Essentially I did my x-calculations wrong, leading me to always be off by one with regards to t.
Also yes, I tested that one.
If you make cN (c big N) and then compute c + 1 - t for that cell in (e, 1) you will get the cell in (e, 1) where a = cN' (Shadow n).
Example:
c = 259, n = 114
a[122] = 29526 (3, 1)
259 + 1 - 122 = 138
a[138] = 37814 (3, 1)
29526 / 259 = 114
37814 / 259 = 146 (shadow n)
Also note that 122 = 130 - 8 ((1 + 259)/2 = 130)
and 138 = 130 + 8 (also note 8 is half of d).
So cN and cN' exists in (e, 1) at t = (1+c)/2 - d/2 and t = (1+c)/2 + d/2.
So 259 = 7x37
a[122] = 114 * 259 = 2319 * 7*37
2 + 1 - 122 = -119
3 + 1 - 122 = -118
19 + 1 - 122 = -102
7 + 1 - 122 = -114
37 + 1 - 122 = -84
a[-119] = 28562
a[-118] = 28086
a[-102] = 21014
a[-114] = 26222
a[-84] = 14282
28562/2 = 14281
28086/3 = 9362
21014/19 = 1106
26222/7 = 3746
14282/37 = 386
It works, your code is not correct if you need a[p + 2 - t]. You're probably starting the index at zero instead of one. With the grid we start with the first cell in (e, 1) being index = 1.
At this point I wonder if the solution is staring us in the face, like we're glossing over the obvious pattern and we're not even realizing it.
Maybe it's the a[p + 1 - t], but in a way we haven't noticed or realized. Maybe the a[p + 1 - t] is a hint and not the solution. For example, do we have d[p + 1 - t] = something? Is it limited to a? what about x or some other variable like i, is the triangle also related in such a way? A whole cell? What if n is also somehow tied into that pattern. We know a is, so maybe there are similar patterns, but we got stuck on a[p + 1 - t]?
Just ranting a bit. And I want to say thank you again AA. You've been tremendous in gather the patterns, for real hands down MVP.
No it wouldn't be O(1). So far, everything involved requires us to calculate d which would require O(sqrt) (or O(log n) as you put it).
If we need to go recursive and we need to factor d and e, does that mean the other approaches VQC has talked about in the past (triangle, -f and e … ) are just approaches that won't work (or will, but with a too high complexity)? Or do you think it all ties in together?
Almost, you're missing half of them. So we can reason a simple method of finding the e's without the need for brute forcing by just using algebra.
We have two equations, one for even e and one for odd e.
even e:
2(t - 1)(t - 1) + e/2 = a
odd e:
2t(t-1) + (e+1)/2 = a
What we're talking about now is solving for a, which will be our c.
2(t - 1)(t - 1) + e/2 = a
4(t - 1)(t - 1) + e = 2a
e = 2a - 4(t - 1)(t - 1)
2t(t-1) + (e + 1)/2 = a
4t(t-1) + e + 1 = a
e = 2a - 4t(t-1) - 1
Example:
We want to find which e's a[1] = 145. There's two of them.
290 = 2145 - 40*0
289 = 2145 - 41*0 - 1
Since a[1] is a bit bland, let's find the e where a[3105] = 145
2145 - 43104*3104 = -38538974
2145 - 43105*3104 - 1 = -38551391
And the records in the cells:
{-38538974:1:6353:6208:145:12563}
{-38551391:1:6354:6209:145:12565}
You can also use this to find columns where c exists in a specific n (for some e).
Say we want to find the columns where there is an a[t] = 145 in (e, 5).
25145 - 4t(t-1) - 1
25145 - 4(t-1)(t-1)
This takes advantage of the fact that if 5*145 exists in (e, 1) then 145 exists as an a in (e, 5) (At the same time 5 exists in (e, 145)).
Yeah. It's kind of hard to verify that it generates the accurate records. I'm not 100% sure since the numbers are so big, but it appears to work for smaller numbers, so I think it's fine. I included the first records for RS100: https://pastebin.com/nart63j2
One thing I noticed while checking with regards to smaller numbers (so it could be a fluke) is that all the e's where c exists in row 1 are also numbers that are part of phi(2c) with a few exceptions (ie a few numbers that divide c). I was looking into it to see if that meant we could take advantage of this to factorize, but that is still no dice given the amount of values to iterate over for a large number.
I was thinking about >>8433 and why we're looking at c at a[1], a[2].. and I started to think about these hints from a while ago:
> When does c first appear at a[t]?
> When is the second time it appears?
I decided to see how many E's squared numbers appear in. The number of e's per square correlate with the Beatty sequence (A001951). That is, 11 appears in column 1, 22 appears in 2 columns, 33 appears in 4 columns… The number of e's that the first 72 squares have match the numerical sequence of Beatty sequence for floor(nsqrt(2)).
I did a quick check against the first 5000 squares and the first 5000 values of floor(n*sqrt(2)) and it appears to check out.
How did you do this?
I'm still not entirely sure what I'm looking at, I need to think some more about it, but I noticed something.
Big N and shadow Big N seems to always appear as a u for the value of e that c exists in, but the value they exist in also seems to act like a map.
Take 259 for example, it has Big N = 114 and shadow N = 146.
The getU simply calculates the u-value of the numbers, so by doing it in reverse we can do sqrt(8(114115/2) + 1) = 229 and sqrt(8(146*147/2) + 1) = 293. The records for these two are:
{4:100:15:14:1:229}
{4:130:17:16:1:293}
The two records for 259 are:
{3:114:16:15:1:259}
{3:146:-16:-17:1:259}
So we can see a method of moving between these records. 100 + 14 (n + x for 229) = 114 and 130+16 = 146 (n + x for 293). This also means we could move across e's and n's on a diagonal (But this does not conserve the c-value).
For example {3:114:16:15:1:259}, we can now move diagonally by doing 114 - 1415/2 = 9 and 3 + 1415/2 = 108. That means at e = 108, n = 9 exists. It should be noted that those numbers got my heart to jump. 108 is the smooth number for 259 (114 - 6) and 9 is the x-value of a=7, b=37, but a quick reality check against other numbers slowed it down. This also works moving "up" with n and "down" on the e.
114 + 15 = 129 (e=2)
129 + 14 = 145 (e=1)
145 + 13 = 162 (e=0)
Fyi I wouldn't think of this as what VQC has talked about when he says "diagonally". I'm not sure if it's a fluke, or exists because of how numbers are connected or what, but it allows for navigation / moving around cells.
For example:
You can start at (5, 1, 1) and end up at (0, 8, 1) moving through these records:
{5:1:4:1:3:7}
{4:2:4:2:2:10}
{3:2:2:1:1:7}
{2:3:3:2:1:11}
{1:5:4:3:1:17}
{0:8:5:4:1:25}
I don't know if this movement makes any sense. I might be going down a new rabbit hole that isn't going to span out.
Lovely to see another anonymous poster (Been a while since we've seen you)!
I've been playing with t a[t] = c patterns and I made a few images. Each show the progression of the pattern as more factors are added.
Prime numbers don't have much in the sense of interesting patterns. As you increase the number of factors the interleaving patterns increase.
Note, white is c, black is 1 and the other colors are either prime factors or sub-compositional numbers.
I'm guessing this isn't much noteworthy stuff then? Either way, to give some background. Each row of pixels represent column e_t where e is a column where c exists as a[t]. The first row is where a[1] = c, second row is a[2] = c etc.
The color grid represents gcd-value between a[t] and c. So in the first (very tiny) image we have 5 (but the same pattern holds for all primes) while the second is two primes. Black is gcd(a, c) = 1, white is gcd(a, c) = c. The rest are randomly assigned based on gcd(a, c) != 1 / gcd(a, c) != c.
Given 2 primes you have 3 values, a, b and ab (Note this relates to >>7901). For three prime factors you have a, b, c, ab, ac, bc and abc.
The length of the row (width) is equal to c, so each image represents a grid of c * c. The problem, as I see it with regards to this structure is aligning them.
You can also see that it is in reality just 8 triangles, each equal and it generates a square pattern where there are multiple squares depending on the number of factors. Each type of square represents a factor.
What is very neat though is the beauty of the patterns it creates. It's stupidly slow, even when multi threaded and partially generated since it involves so many different values. It could probably be more optimized and my machine isn't the fastest.