>>7990

>c=i^2+ij-ji-j^2

Thanks for this perspective.

Using ij = (d+n)(x+n) as the mid-point between the large and small squares, went looking for a way to either directly calculate a factor or reduce the iterative search space for finding the solution small square.

Pics attached explore the ij = (d+n)(x+n) "middle" rectangle for various test cases, and includes a square/triangle breakdown for c6107 as an example of how factors could be extracted from this middle area.

The analysis is based on the formulas (DPN - ij) and (ij - XPN), where DPN = (d+n)^2 and XPN = (x+n)^2.

Reason for this approach is that the a[t] values from the na transform (-f,1) and (e,1) starting records are either very close to or an exact match with the (ij - XPN) or (DPN - ij) values. (see c145 as an example).

The "gcd" and "sqrt" columns provide an alterative way to find the solution "a" values and are calculated as:

gcd = gcd(c,(ij - XPN))

sqrt = sqrt((DPN - ij) - (ij - XPN))

Both formulas return the solution "a" value, except for c363 where the gcd result is a^2.

Additional testing has found that the following gcd formulas also work:

a = gcd(c,(ij - XPN))

a = gcd(c,(DPN - ij))

b = gcd(c,(ij + XPN))

b = gcd(c,(DPN + ij))

Furthermore, the sqrt formula (DPN - ij) - (ij - XPN) can be simplified to aa=(d-x)^2. Indicating again the need to find the correct "x" value.

One way to take advantage of these formulas would be to somehow calculate or iterate to the (ij - XPN) value. The last 2 columns using the min_a variable were an attempt to isolate and understand these gaps (2d+1 keeps appearing).

Alternatively, this analysis may lead to an improved iterative search estimated x+n starting position based on the na (e,1) a[t] value.

For c6107, that starting position would be x+n = sqrt(2976) = 54, and reduces the iterative search space by half (see pic attached).

>>8133

Weird "flood detected" and "alacrity" errors during post.

Duplicate deleted.

>>8110

Pic attached is for triangle numbers between 500 and 530 and includes variables previously hinted for the ColumnKeys function.

The n/a columns represent c mod 4 = 2 numbers that don't exist in the grid. These require c/2 to find valid entries.

n values of 22 and 23 have been highlighted to show perhaps similar behaviors that needs to be explored further.

Interesting that in some cases the sqrt(2d), sqrt(f), or sqrt(e) values come very close to a correct n.

>>8135

Integrated the gcd(d,e) and remainder tree into previous work on the ColumnKeys function, and found a number of cases where "e" represents either a valid x or x+n.

Pic attached is for odd c values between 10000 and 12500 where e mod 4 = 3.

In some cases, a factor can be found simply by a = gcd(d,e) != 1.

In others, the "x in tree" column indicates where in the remainder tree a matching x or x+n value from a factor record is found:

(e x1) indicates x=e at the first branch of the tree.

(e xpn2) indicates x+n=e at the second branch of the tree.

For c12247, as an example, the factor record is found at x+n=e=147.

For c5247, where there are multiple factors, interesting that factor records appear both where x=e and x+n=e.

Not yet sure what family of numbers this x=e and x+n=e can be used to factor.

>>8163

Some additional proof of concept tests on the x=e and x+n=e idea.

These examples are for all odd c values between 9000000000 and 9000100000.

x=e tests are resolved simply by a=d-x, and c % a = 0. Records are created by e,d, and abs(a).

x+n=e tests use the n0 and rm2dnm1 triangle solution from the (x+n)(x+n) square. Records are then created by e,n,d.

Looked a bit deeper into Euler's totient function.

fi(c) is calculated as the number of values k between 1 and c where gcd(k,c) == 1.

fi(145) = 112

Fruitful discussion on the discord yielded some pretty incredible equations (courtesy of Jan) using fi:

145 = 5 x 29

112 = 4 x 28

fi(c) = (a − 1)(b − 1)

fi(c) = ab − a − b + 1

fi(c) = c − a − b + 1

a+b = c - fi(c) + 1

we know:

(a+b)/2 - d = n

a+b = 2(d+n)

Therefore, we can define d+n in terms of c and fi(c) as follows:

d+n = (c - fi(c) + 1) / 2

c145

(1,5,4) = {1:5:12:7:5:29} = 145; (d+n)=17

fi(145) = 112

d+n = (145 - 112 + 1) / 2 = 17

c6107

(23,36,24) = {23:36:78:47:31:197} = 6107; (d+n)=114

fi(6107) = 5880

d+n = (6107 - 5880 + 1) / 2 = 114

>>8251

Also found an alternate way to calculate n using fi using the (e,1) a[t] value from the na record.

n = a[t] - (fi(c)/2)

c6107

(e,1) na: {23:1:3053:77:2976:3132}

solution: {23:36:78:47:31:197}

fi(6107) = 5880

n = 2976 - (5880/2) = 2976 - 2940 = 36

c901

(e,1) na: {1:1:450:29:421:481}

solution: {1:5:30:13:17:53}

fi(901) = 832

n = 421 - (832/2) = 5

c34117

(e,1) na: {261:1:17058:183:16875:17243}

solution: {261:27:184:75:109:313}

fi(34117) = 33696

n = 16875 - (33696/2) = 27

>>8252

Pic attached is a revised columnkeys test incorporating the fi(c) calculation for odd c values between 6000 and 6500.

The formula posted previously, and shown in the last column, can be simplified to:

n = N - fi(c)/2

where N is from an entry c record, and n is in the prime solution record.

Reviewing the data, this n formula works where c is the product of 2 primes for both odd and even parities of n. See odd n c6019, c6023, c6031 and even n c6001, c6005, c6103, c6107 as examples.

When c is a prime number, the formula returns -(d-1) or -x (same value for an odd entry record). See c6007, c6011, c6029, etc.

Not quite sure what the return value means for c with many factors, but perhaps this is where the algorithm comes into play.

Based on this, it appears that a direct calculation is possible for the product of 2 primes - depending, of course, on a grid solution to the fi value for any c.